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The  purpose  of  this  Investigation  was  to  design  and  Implement  a 
graphics  based  envIronmentVcapable  of  supporting  the  rapid  prototyping  of 
pictorial  cockpit  displays.  Attention  was  focused  on  the  interactive 
construction  of  pictorial  type  cockpit  displays  from  libraries  of  cockpit 
displays  and  symbology. 

Implementation  was  based  on  an  object-o'ipnted  programming 
paradigm.  This  approach  provided  a  natural  and  consistent  means  of 

mapping  abstract  design  specifications  into  functional  software. 

t 

Implementation  was  supported  by  an  object-oriented  extension  to  the  CT 
programming  language. 

Although  this  Investigation  addressed  a  specific  application,  the 
resulting  graphic  environment  is  applicable  to  other  areas  requiring  the 
rapid  prototyping  of  pictorial  displays. 
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A  GRAPHICS  ENVIRONMENT  SUPPORTING  THE  RAPID  PROTOTYPING  OF 

PICTORIAL  COCKPIT  DISPLAYS 


L  Introduction 


The  demand  for  cockpit  displays  has  currently  surpassed  the 
capabilities  for  generating  them.  An  ever-increasing  time  lag  between 
requirements  definition  and  implementation  has  developed.  Cockpit  display 
generation  can  take  from  weeks  to  years  to  implement  adding  to 
development  cost  and  reducing  research  effectiveness  [AFWAL  AC/CSRL 
Technical  Program  Plan,  19851  Two  major  factors  have  contributed  to  the 
current  cockpit  display  shortage.  They  are  the  lack  of  automated  design 
tools  and  the  lack  of  a  reusable  software  base  for  cockpit  display 
development 

Currently,  cockpit  display  design  Is  a  tedious,  manual  process.  Tools  to 
support  rapid  prototyping  of  generic  cockpit  displays  are  almost 
non-existant  The  few  tools  that  do  exist  are  usually  tailored  to  a  specific 
display  type  (eg.  Head  Up  Displays)  [Adams,  1985]  severely  restricting  their 
applicability  to  other  display  types.  Software  bases  suffer  from  similar 
llmltiations.  They  either  don't  exist,  must  be  generated  manually,  are 
tailored  to  a  specific  cockpit  display  type,  or  are  so  device  dependent  that 
portability  is  impossible. 
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Figure  1.  Heads  Up  Display. 


This  thesis  proposed  a  partial  solution  to  this  problem  by: 

1 )  developing  a  set  of  automated  design  tools  capable  of  supporting  the 
rapid  prototyping  of  multiple  cockpit  display  types,  and 

2)  establishing  a  reusable  on-line  software  base  to  aid  cockpit  display 
construction. 

These  solutions  were  realized  in  a  highly  Integrated.  Interactive 
graphics  environment.  This  environment  provided  a  dynamic  medium  for  the 
rapid  prototyping  of  multiple  display  types  by  providing  the  capability  of 
constructing  cockpit  layouts  and  cockpit  symbology  from  an  on-line 
software  base  of  cockpit  layouts  and  cockpit  symbology.  Layouts  were 
constructed,  in  a  building  block  fashion,  by  selecting  existing  cockpit 
layouts  and/or  cockpit  symbology  from  a  software  base  and  pasting  them  on 
a  representation  of  an  actual  cockpit  display.  Figure  1  Illustrates  a  Heads 


Up  Display  (HUD)  constructed  via  this  methodology.  Individual  cockpit 
symbols  are  constructed  in  a  similar  manner  from  a  set  of  graphic 
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primitives.  The  ability  to  construct  both  cockpit  layouts  and  cockpit 
symbology  on-line  makes  this  environment  a  feasible  solution  for  the 
cockpit  design/research  problem. 

Ri»ltgmnnd 

currant  Methodology  Currently,  the  design  and  Implementation  of  a 
cockpit  layout  design  Is  a  long  and  tedious  process.  It  requires  many  steps, 
each  performed  manually  by  different  experts.  These  steps  are: 

-  Design  Layout  and  Analysis 

-  Design  Translation  to  Software 

-  Integration  with  Aircraft  Simulation  Models 

-  Testing  and  Evaluation 

Design  layout  and  analysis  Is  the  act  of  capturing  the  designer's 
Ideas  on  paper.  Cockpit  layouts  art  assembled  in  a  building  block  fashion 
from  pre-deflned  sets  of  cockpit  components.  Components  are  selected  and 
positioned  on  the  layout  New  components  ore  created  and  saved  as 
requirements  dictate.  The  final  layout  can  be  viewed  as  a  collection  of 
cockpit  components  spatially  arranged  to  satisfy  a  design  requirement 
When  the  layout  is  complete,  It  Is  transferred  to  software  and 
simulation  experts  for  translation  Into  computer  code.  Each  component  may 
be  realized  with  an  associated  subroutine  or  procedure.  It  Is  the 
responsibility  of  the  software  and  simulation  experts  to  create  source  code 
files,  composed  of  the  various  procedures,  into  a  single  application  for 
testing.  New  components,  with  no  associated  code,  will  require  individual 
design,  coding,  and  testing  before  they  are  Integrated  into  the  final 
application. 


Introduction 


3 


The  amount  of  time  and  code  required  during  this  phase  depends 
directly  on  the  complexity  of  the  layout  Layouts  that  are  slight 
modifications  to  existing  ones,  require  a  minimal  amount  of  software  to  be 
generated  A  new  layout  with  new  components  will  require  extensive  time 
and  software  resources.  In  either  case,  design  translation  Is  an  expensive 
and  time  consuming  activity.  It  requires  extensive  debugging  and  testing  of 
each  Individual  component  and  system  testing  of  the  final  design. 

After  the  design  has  been  translated  to  code,  it  Is  Integrated  with 
various  aircraft  simulation  models  for  testing.  This  step  can  also  be  very 
time  consuming  and  resource  expensive.  The  result  of  this  step  is  a 
complete  software  simulation  of  the  cockpit  design  constrained  by  the 
specific  aircraft  characteristics,  ready  for  testing  by  the  designer  and  the 
Intended  user. 

The  final  software  product  Is- than  Installed  within  a  simulation 
cockpit  for  testing.  It  Is  at  this  stage  that  the  user  and  designer  can 
actually  ‘fly*  the  design.  If  testing  reveals  that  modifications  to  the  current 
layout  are  necessary,  the  layout  la  re-cycled  through  the  process  outlined 
above.  Although  redesign  Is  usually  not  as  an  extensive  development  effort 
as  the  original  design,  it  still  consumes  a  considerable  amount  of  time  and 
support  resources. 

ecoblama.  Four  major  problems  exist  with  current  methodology;  they 
are  as  follows: 

-  Tedious  (manual)  Process 

-  Time  Consuming 

-  Non-Responsive 

-  Device  Dependent 
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On#  of  the  main  problems  with  the  current  methodology  is  that 
virtually  all  steps  are  performed  manually.  Design  layout,  analysis,  and  any 
required  corrections  are  manually  performed  on  paper.  Design  translation  is 
performed  by  software  and  simulation  experts  who  manually  write,  debug, 
and  test  the  code.  The  resulting  code  Is  then  manually  Integrated  with 
aircraft  simulation  models  for  dynamic  testing. 

Not  only  Is  the  current  design  process  tedious,  It  Is  also  time 
consuming.  Depending  on  the  complexity  of  the  design,  Implementation 
(from  design  conception  to  testing  and  evaluation)  can  take  from  weeks  to 
years  to  complete.  By  the  time  the  design  Is  Implemented,  the  designer  Is 
pursuing  other  layout  schemes  or  the  current  layout  Is  no  longer  pertinent. 

The  drudgery  of  the  manual  process,  coupled  with  an  ever-increasing 
time  delay  between  Idea  conception  and  Implementation,  fosters  a  design 
process  that  is  non-responsfve  to  the  designer's  needs.  The  current  process 
does  not  provide  the  designer  with  an  effeclve  or  efficient  means  of 
evaluating  and  modifying  the  design  In  a  continuous,  and  timely,  fashion.  The 
designer  becomes  as  outside  participant  in  the  design  process  once  the 
design  translation  begins.  Not  until  the  test  and  evaluation  phase  can  the 
designer  Interject  Inputs  to  the  design  process.  Then,  all  errors  or 
modifications  Identified  result  In  the  software  being  turned  over  to 
software  and  simulation  experts  for  re-work.  This  can  entail  lengthy 
modification,  testing,  and  debugging  before  the  software  Is  returned  to  the 
designer.  Simple  changes  can  take  weeks  to  Implement.  The  ability  to  fine 
tune  designs  becomes  almost  Impossible  due  to  the  time  and  resource 
expenses  Involved. 
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Another  factor  contributing  to  the  non-responslve,  inflexible  nature  of 
the  current  design  process  Is  the  software  dependencies  on  specific 
hardware  devices.  Due  to  the  heterogeneous  nature  of  the  hardware 
environment,  much  of  the  software  written  to  Implement  cockpit  displays  is 
device  dependent.  Rehosttng  a  design  (1.a.  the  software)  often  entails  a 
duplicate  development  effort.  The  original  software  may  require  a  complete 
re-design  to  function  on  the  new  hardware.  Even  a  minimal  rehosting  effort 
will  require  extensive  testing  and  debugging  of  the  new  software  In  its  new 
hardware  environment  to  ensure  compliance  with  original  requirements. 

DESIGNS.  Research  to  provide  an  alternative  to  the  current 
methodology  was  undertaken  and  reported  In  the  1985  Air  Force  Institute  of 
Technology  (AFIT)  thesis  entitled  "A  Display  Environment  Supporting  the 
Interactive  Generation  of  alphaNumerfcs  and  Symbology  with  DESIGNS  on  the 
Future"  (referred  to  as  DESIGNS).  DESIGNS  had  two  goals:  1)  to  demonstrate 
the  feasibility  of  using  a  graphics  based  environment  for  the  generation  and 
editing  of  display  formats  and  2)  the  automatic  generation  of  source  code 
from  the  display  format  for  a  targeted  graphics  device  [Adams,  1985:501. 

To  accomplish  these  goals,  an  Initial  system  was  implemented  to 
develop  and  modify  HUD  formats.  The  designer  could  Interactively  lay  out 
HUDs  from  pre-deftned  sets  of  HUD  symbols.  Code  was  automatically 
generated  from  a  layout  by  linking  together  source  code  associated  with 
each  HUD  symbol  In  the  display.  The  source  code  and  the  symbols  were 
maintained  In  on-line  libraries.  Manual  Intervention  was  confined  to  the 
layout  process. 

DESIGNS  significantly  reduced  the  time  required  for  static  HUD 
implementation  from  weeks/months  to  an  average  of  30  minutes.  The  30 
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minutes  included  actual  HUD  layout  activity  and  subsequent  software 
generation  [Adams,  19861  It  should  be  emphasized  that  aii  HUD  layouts 
were  constructed  from  pre-existing  symbol  sets.  Dynamic  inclusion  of  new 
symbols  was  not  directly  supported  by  DESIGNS.  The  designer  was  still 
dependent  on  software  experts  to  manually  Integrate  new  symbols  into  the 
DESIGNS  environment 

ac/csbl  .  using  DESIGNS  as  a  baseline  for  development,  the  Air  Force 
Wright  Aeronautical  Laboratories,  Flight  Dynamic  Laboratory  (AFWAL/FIGR, 
FIGD)  initiated  research  directed  toward  implementing  an  Advanced 
Cockpit/Crew  Station  Research  Laboratory  (AC/CSRL).  The  goal  of  the 
AC/CSRL  Is  to  automate  the  entire  cockpit  design  process,  with  the  main 
objective  of  keeping  the  designer  as  the  focal  point  of  all  aspects  of  the 
design  process.  Currently  the  AC/CSRL  Is  In  definition  phase; 
Implementation  Is  not  expected  until  the  1990's. 

AC/CSRL  Is  expected  to  support  the  following: 

-  interactive  design  and  modification  of  cockpit  layouts, 

-  automatic  generation  of  source  code  from  the  design, 

-  automatic  linkage  to  aircraft  simulation  models,  and 

-  one  day  turnaround  time  to  prepare  completely  new  cockpit 
arrangements  for  testing  [AFWAL  AC/CSRL  Technical  Program 
Plan,  19851 

Unlike  DESIGNS,  which  only  supported  the  development  of  HUO-type 
displays,  the  AC/CSRL  will  support  a  variety  of  displays,  from  simple 
alphanumerlcs  to  complex  pictorial  type  displays,  in  addition,  the  AC/CSRL 
will  also  support  dynamic  creation  and  integration  of  new  cockpit 
symbology  Into  the  design  environment 
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Figure  2.  AC/CSRL  Concept 


To  accomplish  this,  ths  AC/CSRL  wilt  rely  heavily  on  a  flexible 
graphical  Interface  and  on  on-line  libraries  of  cockpit  symbology  and 
associated  source  code.  Displays  will  be  constructed  in  a  building  block 
fashion,  by  selecting  cockpit  symbols  from  the  libraries  and  placing  them  on 
a  repesentatlon  of  an  actual  cockpit  display.  Source  code  will  then  be 
automatically  generated  and  combined  with  aircraft  simulation  packages  to 
produce  a  full  mission  scenario.  The  designer,  in  effect,  will  be  able  to 
construct  a  design  layout,  generate  the  corresponding  code,  and  dynamically 
test  the  design  within  the  same  environment  The  design  process  will  no 
longer  be  dependent  upon  software  and  simulation  experts,  thus  Improving 
turnaround  time  and  reducing  costs.  Figure  2  conceptually  depicts  the 
AC/CSRL  concept  with  its  associated  components. 

At  a  procedural  level  the  AC/CSRL  will  not  drastically  alter  the  nature 
of  the  design  process.  The  same  procedures  performed  in  the  current  manual 
design  process  will  also  be  performed  via  the  AC/CSRL.  However,  the 
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degree  of  manual  intervention  is  significantly  different  between  the  two. 
The  current  process  is  almost  entirely  manual.  Few,  if  any,  of  the  steps  are 
automated.  In  contrast,  the  goal  of  the  AC/CSRL  is  to  automate  the  entire 
process. 

Design  layout  and  analysis  will  be  supported  Interactively  via  a 
flexible  graphics  interface,  known  as  the  Automated  Layout  Center  (ALC). 
The  ALC  is  the  focal  point  of  all  cockpit  design  activity.  All  cockpit  layout 
design  as  well  as  cockpit  symbology  construction  is  handled  through  the 
ALC  It  provides  the  designer  with  a  window  Into  the  AC/CSRL  environment. 

Testing  will  be  significantly  enhanced.  Complete  simulation  senarlos 
will  be  generated  for  the  designer  and  Intended  user  to  test  (l.e.  'fly')  and 
evaluate.  Redesign  will  be  supported  In  a  more  timely  manner.  It  should  be 
possible  to  Incorporate  modifications  and  retest  a  redesign  within  the  swne 
day,  as  opposed  to  weeks  In  the  current  process.  This  should  significantly 
Improve  productivity  and  promote  experimentation  of  alternative  display 
representations. 

Problem  Statement 

The  qoal  «f  this  thesis  research  was  to  demonstrate,  in  part,  the 
feasibility  of  the  AC/CSRL  concept  by  designing  and  implementing  a 
prototype  of  the  Automated  Layout  Center.  The  prototype  ALC  focused  on 
the  rapid  prototyping  of  pictorial  type  cockpit  displays  via  the  use  of 
on-line  libraries  of  cockpit  layouts  and  cockpit  symbology.  In  addition  to 
addressing  a  rapid  prototyping  capability,  this  thesis  also  presented  a 
candidate  user  Interface  for  the  ALC. 
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The  Implementation  of  the  prototype  ALC  was  based  on  an 
object-oriented  paradigm.  An  object-oriented  approach  was  chosen  because 
It  provided  a  framework  that  was  a  "direct  and  natural  correspondence 
between  the  world  (/a  tha  design  process)  and  Its  model  (/a  *  virtual 
cockpit  display)'  [Borglda  et  al.,  1985:851  (Italic  phrases  added  by  author). 
To  suppport  such  an  Implementation,  an  object-oriented  extension  of  the  'C 
programming  language  was  Implemented.  These  extensions  were  modeled 
after  the  Smalltalk  environment  (Goldberg  and  Robson, 19831 


The  objective  of  this  thesis  was  to  design  and  Implement  a  prototype 
ALC  supporting  the  rapid  prototyping  of  cockpit  displays.  The  results  from 
this  effort  were  to  be  used  as  guidelines  for  future  AC/CSRL  related 
projects.  Since  this  was  a  rather  ambitious  project,  the  following 
constraints  were  placed  on  this  research  effort 

Breath  of  Implementation.  The  prototype  ALC  design  consisted  of 
four  functions?  Teas;  1)  the  user  Interface,  2)  the  Layout  Editor,  3)  the 
Symbol  Editor,  and  4)  the  Librarian.  The  user  Interface  provided  the  dynamic 
medium  through  which  all  user  Interactions  cyston  responses  wer* 
handled.  The  Layout  Editor,  a  graphics  editor,  supported  the  dynamic 
prototyping  of  cockpit  layouts.  The  Symbol  Editor,  another  graphics  editor, 
supported  the  creation  and  modification  of  cocxpit  symbology.  The  Librarian 
provided  an  archival  mechanism  used  to  store  and  retrieve  cockpit  layouts 
and  cockpit  symbols. 
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Out  to  time  constraints  and  for  dtmonstatlon  purpose,  only  ths  ustr 
Inttrfac#  and  Layout  Editor  ware  impltmtnttd.  The  exclusion  of  the  Sym  bol 
Editor  and  Librarian  did  not  significantly  distract  from  the  goal  of 
demonstrating  the  feasibility  of  the  ALC  concept.  However,  for 
completeness  and  future  implementation,  the  requirements  definition  and 
design  of  all  four  functional  areas  are  presented  in  this  thesis. 

Display  Dimensionality.  The  AC/CSRL  is  expected  to  support  the 
creation  of  both  two  and  three  dimensional  cockpit  display  representations. 
The  prototype  ALC  supported  only  the  design  and  representation  of  two 
dimensional  cockpit  displays.  Three  dimensional  cockpit  display 
representation  will  be  an  essential  component  of  future  displays;  however, 
including  this  capability  within  this  thesis  would  only  serve  to  distract 
from  the  fundamental  characteristics  of  the  ALC  that  needed  to  be 
addressed  first  The  ALC  prototype  design  does  not  explicitly  rule  out  the 
Inclusion  of  three  dimensional  capabilities,  but  on  the  other  hand,  it  does 
not  explicitly  address  It  either. 

end*  fimratioiv  The  AC/CSRL  will  automatically  generate  source 
code  from  the  cockpit  designs  created  on  the  ALC.  Code  generation  is  not 
addressed  in  this  thesis.  The  prototype  ALC  only  supports  the  creation  and 
modification  of  cockpit  layout  formats;  ft  does  not  generate  source  code 
from  said  layouts. 

input  Davicea.  This  thesis  cannot  address  the  merits  of  which  Input 
devicets)  should  be  used  to  interface  with  the  prototype  ALC.  Although  the 
AC/CSRL  will  stt.'-vt  many  devices,  time  constraints  and  the  lack  of 


if 
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available  Input  devices  for  Interfacing  prohibit  consideration  In  this  thesis. 
As  such,  the  primary  means  of  Interaction  will  be  via  a  mouse.  The  keyboard 
is  used  for  retrieval  of  textual  Information  only  (l.e.  filenames,  labels,  etc.). 

Transportability  .  a  key  requirement  of  the  AC/CSRL  is  device 
Independence.  Device  Independence  will  allow  re-targeting  of  the  AC/CSRL 
designs  on  different  graphic  devices.  This  Is  not  attainable  for  the  prr '  type 
ALC  due  to  the  unavailability  of  appropriate  systems. 

Although  the  design  Is  device  Independent,  the  implementation  Is 
targeted  to  a  Raster  Technologies  Model  One/25  graphics  system.  As  such, 
some  sections  of  the  code  will  be  device  dependent.  These  sections  have 
been  Identified  and  Isolated  as  much  as  possible. 

Sifluanauit.  Praaantatlon 

The  second  and  third  chapters  of  this  thesis  present  the  system 
requirements  and  overall  system  design.  Chapter  2  addresses  system 
requirements  related  to  three  general  areas;  hardware,  software,  and  the 
user  Interface  for  the  prototype  ALC.  Chapter  3  maps  the  system 
requirements  into  four  functional  areas  that  comprise  the  ALC  prototype's 
design,  namely;  the  user  Interface,  Layout  Editor,  Object  Editor,  and  the 
Librarian. 

The  fourth,  fifth,  and  sixth  chapters  describe  in  detail  the  design  of  the 
four  functional  area  defined  In  Chapter  3.  Chapter  4  addresses  the  design  of 
the  user  Interface,  discussing  what  design  considerations  were  followed 
and  the  actual  Interactive  components  that  comprise  the  user  interface. 
Chapter  5  discusses  the  similarities  and  differences  between  the  Layout 
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Editor  and  the  Symbol  Editor.  Chapter  6  provides  insight  into  the  design  of 
the  prototype  ALCs  archival  mechanism,  the  Librarian. 

Chapter  7  deals  with  the  actual  implementation  of  the  ALC  prototype. 
Implementation  is  approach  from  three  viewpoints.  The  first  view  is  a 
description  of  the  actual  host  hardware  for  the  ALC  prototype.  This  is 
followed  by  a  description  of  the  object-oriented  environment  used  in 
Implementing  the  ALC  prototype  software.  And  finally,  a  description  of  the 
ALC  prototype  implementation  is  presented  Chapter  8  concludes  the 
written  thesis  with  conclusions  regarding  the  success  of  this  research 
effort  and  recommendations  for  the  future. 

The  appendices  of  this  thesis  provide  information  relative  to  the 
software  and  hardware  environments  in  which  the  prototype  ALC  was 
hosted  Specifically,  Appendix  A  addresses  the  design  approach  followed  in 
the  conceptualization  of  the  software.  This  is  followed  in  Appendix  B  with 
a  basic  overview  of  the  object-oriented  concepts  that  were  used  to  model 
the  implementation  or  the  prototype  ALC  software.  Appendix  C  provides  a 
detailed  discussion  of  the  object-oriented  extensions  to  the  'C*  language 
that  were  implemented  to  support  the  prototype  ALC  implementation. 
Appendix  D  outlines  the  graphic  capabilities  (1.e.  classes)  that  are  currently 
supported  by  the  object-oriented  implementation.  Appendices  E  and  F 
describe  the  operational  characteristics  of  the  Raster  Technologies  Model 
One/25  and  associated  device  drivers. 
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There  are  three  primary  areas  of  requirements  for  the  ALC  prototype 
that  this  chapter  will  define.  They  are  the  hardware,  software,  and  the  user 
interface  areas.  Hardware  requirements  encompass  the  actual  hardware 
needed  to  support  the  prototype  ALC  The  software  requirements  section 
describes  the  functional  requirements  and  provides  guidelines  for  software 
development  User  Interface  requirements  bind  the  hardware  and  software 
requirements  together.  A  detailed  description  of  each  requirement  category 
Is  presented  In  the  following  sections. 

Hardware 

Although  no  hardware  Is  being  designed,  and  the  target  host  has  already 
been  Identified.  It  is  still  worth  mentioning.  In  general  terms,  the  hardware 
requirements  needed  to  support  the  ALC  prototype.  This  section  provides 
general  guidelines  to  follow  If  the  ALC  prototype  Is  re-hosted  at  some 
future  time. 

There  are  four  general  areas  that  the  hardware  discussion  should 
address.  These  areas  are  display  technology.  Input  devices,  output  devices, 
and  processing  and  storage  capabilities  [Rose.  1 982:251 

Display  Technology.  Three  basic  types  of  display  technologies  could 
be  used  for  the  ALC  prototype:  vector,  storage  tube,  and  raster.  Each 
technology  uses  a  technique  Known  as  phosphorescence'  to  Illuminate  an 
Image  on  the  display  screen.  This  process  involves  the  use  of  an  electron 
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beam  to  excite  a  phosphor-coated  display  screen  The  phosphor  when 
excited,  jumps  to  a  higher,  unstable  energy  state.  When  the  beam  is 
removed,  the  phosphor  returns  to  Its  original  stable  state  releasing  the 
excess  energy  as  light  Images  are  drawn  by  directing  an  electron  beam  on 
the  phosphor-coated  screen  in  the  desired  shape  or  pattern  The  method 
used  to  direct  the  electron  beam  constitutes  the  major  distinction  between 
the  three  technologies. 

Vector  (or  often  refered  to  as  stroke,  or  calligraphic)  displays  display 
Images  by  directly  tracing  the  Image  on  the  display  screen  with  the  electron 
beam.  This  method  Is  extemely  fast  and  straightforward.  However,  because 
the  illuminated  phosphor  fades  at  a  exponential  rate,  the  image  must  be 
continuously  retraced  (or  refreshed)  for  the  Image  to  remain  on  the  screen 
[Foley  and  Van  Dam, 1982: 1061  As  more  and  more  Images  are  drawn,  an 
annoying  flicker  in  the  display  presentation  may  develop. 

Storage  tube  displays  circumvent  the  flicker  problem  by  tracing  the 
Image  on  a  fine  mesh  grid  mounted  Immediately  behind  the  phosphor  coated 
screen.  Images  traced  on  the  grid  are  transferred  directly  on  to  the 
phosphor.  The  grid  acts  as  a  storage  medium,  saving  the  Image  once  It  Is 
traced.  This  allows  the  image  to  be  drawn  only  once,  eliminating  the  flicker 
problem  caused  by  the  need  to  refresh  the  screen  constantly.  However, 
since  the  image  is  siored  on  the  grid  and  continuously  displayed,  it  becomes 
almost  impossible  to  make  selective  erasures  from  the  screen.  In  order  to 
erase  a  single  Image,  the  entire  display  must  be  erased  and  the  modified 
Image  redrawn. 

Raster  displays  differ  fundamentally  in  the  way  images  are  drawn. 
Unlike  the  refresh  and  storage  tube  displays,  the  image  is  not  directly 
traced  on  the  screen.  Rather  it  is  written  into  a  storage  area  know  as  a 
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Tram*  buffer'.  A  frame  buffer  Is  a  matrix  of  bits,  each  corresponding  to  a 
unique  address  point  (or  pixel)  on  the  screen.  Each  entry  in  the  matrix 
stores  the  brightness  and/or  color  value  for  its  corresponding  screen  pixel. 
An  image  is  displayed  by  processing  the  matrix,  row  by  row,  using  the 
contents  of  each  entry  to  control  the  electron  beam  intensity.  The  image  is 
thus  displayed  row  by  row,  starting  at  the  top  of  the  screen  and  finishing  at 
the  bottom. 

Raster  displays  overcome  the  problems  of  screen  flicker  and  erasure 
problems  associated  with  vector  and  storage  tube  displays.  The  electron 
bean  is  not  required  to  bounce  around  the  screen  tracing  an  image  but  rather 
follows  a  predefined  pattern  (row  by  row)  with  in  a  predefined  time  span 
(30  to  60  times  a  second).  This  allows  a  display  composed  of  many  images 
to  be  drawn  at  the  same  rate  as  a  display  containing  just  a  few  Images.  The 
frame  buffer  provides  a  means  of  doing  selective  erasures  without  the 
entire  screen  having  to  be  erased  and  redrawn. 

The  choice  of  which  technology  to  use  often  depends  on  the  intended 
application.  For  applications  that  require  only  static  displays  and  minimal 
user  interaction;  all  three  technologies  could  be  used.  For  dynamic,  user 
intensive  application,  such  as  the  ALC  prototype,  a  vector  or  raster  display 
would  be  warranted.  Table  I  provides  a  summary  of  the  capabilities  of  the 
three  display  technologies  (Dudley,  1982381 

input  Devices.  The  ALC  prototype  requires,  as  a  minimum,  an  input 
device  capable  of  performing  the  following  two  functions,  t)  cursor 
tracking,  and  2)  object  selection.  A  number  of  Input  devices  could  satisfy 
this  requirement  The  most  commonly  used  devices  are,  the  tablet  or 
digitizer,  touchpanel,  joystick,  mouse,  and  trackball.  The  choice  of  which 
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TABLE! 

Display  Technology  Summary 


Roster  Storage  Tube  Uector 

Resolution 

loui  to  high 

high 

very  high 

Draining  type 

areas, 

realistic 

line 

line 

Motion 

dynamic 

static 

dynamic 

Color 

millions 

green  on 
green 

mono  or 

4  to  8  colors 

Interactiveness 

high 

lorn 

very  high 

Use 

Intelligent 

terminal, 

stand-alone 

dumb 

terminal 

stand-alone 

system 

device  Is  used  will  most  likely  depend  on  availability  of  the  Input  device. 
Table  II  summarizes  software  development  cost  factors,  Input  type,  and 
special  considerations  related  to  these  devices  [Ohlson,  1979:2851 

Output  Devices.  The  ALC  prototype  does  not  require  an  output  device 
other  than  the  display  screen.  If  hardcopies  are  desired,  a  plotter  or  film 
recorder  could  be  used. 

Processing  and  Storage.  The  central  processing  unit  (CPU)  Is  the 
heart  of  a  graphics  system.  Regardless  of  whether  the  graphics  system  Is  a 
stand-alone  or  remote  terminal,  the  computational  processing  capabilites  of 
the  CPU  will  directly  Influence  the  type  of  graphic  applications  that  can  be 
implemented  and  expected  to  execute  within  a  reasonable  amount  of  time. 
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TABLE  II 

Input  Device  Summary 


Device 

Software 
Dev.  Cost 

Input 

Type 

Special  Considerations 

Tablet 

Medium 

Indirect 

6raphical 

Some  Units  are  not 
suitable  for  online 
Interactive  use. 

KuChponel 

Low 

Direct 

Tactile 

Gross  resolution,  makes 
detail  work  Impossible. 

Joystick 

Low 

Indirect 

Tactile 

Large  variety, 
fits  most  applications. 

House 

Low 

Indirect 

Tactile 

Relative  Positioning. 

Trackball 

Low 

Idtfrcct 

Tactile 

Slewing  capabilities. 

Computationally  intensive  applications  such  as  3-dimenslonal  modeling  and 
ray  tracing  require  significant  processing  power,  as  opposed  to  simple  line 
chart  applications.  The  choice  of  which  CPU  to  use  should  be  weighed 
against  the  computational  aspect  of  the  application.  The  ALC  prototype  does 
not  require  an  exceptionally  powerful  CPU.  host  16-bit  microprocessors 
available  on  the  market  today  would  suffice. 

Storage,  both  Internal  (memory)  and  external  (secondary),  also 
Influence  the  speed  at  which  an  application  can  execute.  Applications 
constrained  by  limited  main  memory  or  hampered  by  slow  peripherals,  often 
spend  a  significant  amount  of  time  waiting  for  segments  of  the  application 
to  be  swapped  to  and  from  memory  or  waiting  on  data  transmission  from  the 
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TABLE  III 

Prototype  ALC*s  Hardware  Requirements. 


Requirement  Implementation 

Display  Technolgy 

Refresh  or  Raster 

Input  Deulce 

Cursor  Tracking 
and 

Object  Selection 

Output  Deulce 

Optional 

Processing 

and 

Storage 

16  bit  micro  (minimum) 

1M  main  memory,  10M  disk 

« 

peripheral  device.  Instead  of  performing  useful  work,  the  application 
becomes  'I/O  bound*.  To  prevent  this  from  occurfng  with  the  ALC  prototype, 
the  host  system  should  have  at  least  1  megabyte  of  main  memory  and,  at  a 
minimum,  a  10  megabyte  hard  disk.  Table  III  provides  a  summary  of  the  ALC 
prototype  hardware  requirements. 

SflttMtart 

Software  requirements  for  the  ALC  prototype  can  be  classified  into 
two  areas,  I)  software  development  requirements,  and  2)  Implementation 
requirements.  Software  development  requirements  apply  directly  to  the 
software  development  activity.  They  serve  as  guidelines  to  ensure  that  the 
software  Is  developed  in  a  consistent  and  standard  way.  They  are  general  in 
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nature,  and  should  ba  appllad  to  all  software  development  efforts  regardless 
of  the  application.  Implementation  requirements,  on  the  other  hand,  are 
application  specific.  They  categortally  state  the  functions  that  the  software 
must  perform.  They  address  ‘what*  should  be  Implemented,  not  ’how*. 

Software  PtVilMHntnt  RfttJlrtmtntfi  The  principles  listed  here, 
are  general  software  requirements  that  should  be  adhered  to  In  the  design 
and  development  of  the  actual  aoftware.  These  principles  should  be  applied 
at  all  levels  of  the  development  effort 

Portability  (davlce/hoat  Independence).  The  prototype  ALC  should 
be  designed  with  host  Independence  In  mind.  Since  this  is  a  prototype,  It 
might  be  desirable  to  re-host  this  system  on  different  workstations.  As 
such,  the  software  should  be  developed  with  no  specific  host  in  mind. 
Portions  of  the  software  that  are  dependent  on  the  hardware  should  be 
Isolated  as  much  as  possible  and  clearly  identified. 

Modularity.  The  software  should  be  designed  In  a  modular  manner. 
Modularity  provides  a  method  of  Isolating  the  functions  of  the  software  Into 
well-defined  units.  These  units  range  In  complexity  from  procedure  to 
library  packages  (Fairley,  1985:1451  Some  of  the  benefits  modularity 
provides  are:  ease  of  implementation,  maintenance,  debugging,  and 
complexity  management  [Shooman,  1983:1 101 

simplicity.  The  software  should  be  written  so  It  Is  easy  to  read 
and  understand.  All  software  modules  should  contain  only  one  entry  and  one 
exit  point.  They  should  conform  to  a  consistent  programming  style  and 
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should  not  attempt  to  hide  the  logic  of  the  function  under  clever  coding 
[Fairley,  1965:209-2141  It  should  be  self-evident  what  a  module  does. 
Following  such  conventions  makes  the  software  easier  to  read,  to 
understand,  and  to  modify. 

Efficiency.  Efficiency  refers  to  the  ability  of  the  software  to 
operate  under  the  current  set  of  available  resources.  There  are  two  main 
facets  of  efficiency:  time  and  space  [Booch,  1983:25).  Time  efficiency 
pertains  to  the  ability  of  the  software  and  hardware  to  operate  within  a 
specified  time  constraint.  The  only  time  constraints  Imposed  on  this  project 
are  to  provide  a  flicker-free  display  and  response  to  user  commands  In  a 
reasonable  time.  The  system  should  wait  on  the  user,  not  vice  versa 

Space  efficiency  Implies  that  the  software  should  reside  and  execute 
within  the  current  available  memory.  It  should  not  be  a  requirement  of  this 
research  to  acquire  additional  hardware  of  any  type. 

Extensibility.  To  accommodate  future  modifications,  the  software 
should  be  designed  with  generality  In  mind.  In  other  words,  the  software 
should  provide  a  framework  (harness)  In  which  new  capabilities  (modules) 
can  be  'plugged  In'  [Clemons  and  Greenfield,  1985:401  This  will  allow  the 
system  to  expand  as  user  requirements  change  and  advanced  features  are 
added. 

Table  IV  summarizes  of  the  software  development  requirements. 

Imoltmtnutian  Riqulrimsnta.  Implementation  requirements 
describe  what  the  user  wants  the  software  to  do.  They  are  application 
specific  and  need  to  be  clearly  Identified  before  the  design  or 
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TABLE  IV 

Software  Development  Requirements. 


Requirement 

Portability 

Host  independent 

Modularity 

Isolate  the  functions  of  the 
software  Into  well  defined  units 

Simplicity 

Easy  to  reed  end  leern 

Efficiency 

Operate  with  current  set  of 
euallable  resources 

Eutenslbillty 

Easy  to  add-on  new  capabilities 

implementation  begins.  There  are  five  basic  functions  that  the  ALC 
prototype  must  support: 

-  Graphical  Interaction, 

-  Direct  Manipulation, 

-  Iterative  Development, 

-  Experimentation,  and 

-  Evolutionary  Design. 

6raphlcal  Interaction:  The  process  of  designing  a  cockpit  display 
Is  a  spatially  oriented  activity.  It  relies  heavily  on  graphical  images  to 
represent  cockpit  and  real-world  objects.  As  such,  the  prototype  ALC 
should  exploit  the  use  of  graphics  as  a  medium  for  the  computer-human 
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Interaction.  The  use  of  graphics,  as  a  medium  for  Interaction,  provides 
certain  distinct  advantages  over  the  use  of  text  as  a  medium  [Raeder, 
1965:12]  which  are  particularly  relevant  to  the  ALC  prototype  and  related 
AC/CSRL  efforts.  These  advantages  are  discussed  in  the  following 
paragraphs. 

The  use  of  graphics  as  a  medium  of  Interaction  permits  instant  random 
access  (viewing)  to  any  part  of  the  display  screen.  The  user  can  focus 
attention  on  a  specific  aspect  of  the  display  or  can  'back-off'  to  grasp  the 
overall  structure.  The  user  is  not  forced  to  follow  a  linear  search  pattern, 
but  can  switch  from  object  to  object,  view  to  view,  In  a  random  fashion. 

Text,  on  the  other  hand,  forces  the  user  to  view  information 
sequentially  (usually  top  to  bottom,  left  to  right),  it  becomes  difficult  to 
grasp  the  information  content  of  text  displays.  Headlines,  bold  type,  and 
paragraphs  provide  some  relief,  but  the  process  still  remains  sequential  in 
nature. 

Graphics  provide  multiple  levels  of  dimensionality  to  the  information 
being  displayed.  Information  can  be  portrayed  in  two  or  three  dimensions 
and  the  physical  attributes  of  the  Information  (t.e.  shape,  color,  sf7e,  etc) 
can  also  be  modified.  Text,  on  the  other  hand,  is  a  one-dlmenslonal  faring  of 
characters. 

Graphic  mediums  also  capitalize  upon  the  inherent  Image  proo.  ^Ing 
capabilities  of  the  human  sensory  system.  The  mind,  a  kind  of  biologic  at 
Image  processor,  is  extremely  adept  at  accessing  and  processing  vtsua: 
information.  We  tend  to  conceptualize  things  as  pictures,  not  words.  As  the 
saying  goes,  'A  picture  Is  worth  a  thousand  words'. 

The  use  of  graphics  as  the  main  means  of  interaction  directly 
Influences  the  designer's  perception  of  cockpit  display  creation.  The  process 


Requirements 


23 


of  creating  a  cockpit  display  Is  vary  similar  to  computer  programming. 
Instead  of  using  a  textual-based  language  such  as  Pascal  or  Ada  to  develop 
an  application,  the  designer  uses  a  graphics-based  language  to  build 
(program)  a  display.  The  Immediate  details  of  syntax  and  control  structure 
are  transparent  to  the  designer.  The  designer  deals  directly  with  the 
semantics  of  the  language,  understanding  the  whole  verses  Individual  parts 
or  commands. 

Direct  Manipulation.  An  Important  aspect  of  graphical  interaction 
Is  the  ability  to  manipulate  objects  directly  on  the  screen  (Shneiderman, 
1983:571  Direct  manipulation  refers  to  the  ability  of  the  user  to  modify  the 
characteristics  of  an  object  (l.e.  shape,  size,  color,  position,  etc.)  via  some 
action.  The  user  is  not  required  to  use  an  Intermediate  form  (o.g.  commands 
Issued  from  the  keyboard)  to  Initiate  an  action.  The  user  can  use  some  form 
of  a  pointing  device  to  select  the  object  and  then  directly  manipulate  its 
form.  Direct  manipulation  of  cockpit  objects  Is  a  key  requirement  of  this 
system  [AFWAL  AC/CSRL  Technical  Program  Plan,  19851 

Iterative  Development  The  process  of  developing  cockpit 
displays  is  best  implemented  via  an  Iterative  process.  An  iterative  process 
allows  the  user  to  evaluate  and  modify  the  design  on  a  continuous  basis 
[Shooman,  1983: 361  This  process  should  provide  the  flexibility  to  support 
the  following  required  activities  (AFWAL  AC/CSRL  Technical  Program  Plan, 
19851 

-  implementation  of  new  designs, 

-  Implementation  of  design  changes, 

-  the  fine-tuning  of  designs 
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-  creation  and  modification  of  cockpit  symbology,  and 

-  the  rapid  generation  of  alternative  displays. 

Experimentation.  The  system  should  be  supportive  of 
experimentation.  It  should  allow  the  designer  to  experiment  with  possible 
design  layouts  without  commitment  In  other  words,  actions  performed  by 
the  designer  should  be  'undo-able'  [Harslem,  1984104].  The  ability  to  'undo' 
a  design  decision  allows  the  designer  to  explore  alternative  design 
representations  without  committing  expensive  and  time  consuming 
software  and  personnel  resources. 

A  major  problem  plaguing  the  current  design  process  Is  the  inability  to 
experiment  with  cockpit  representations  'on-the-fly'.  The  designer  is  not 
afforded  the  luxury  of  making  minor  modifications  to  a  cockpit  layout 
without  incurring  additional  time  and  resources  to  the  already  expensive 

design  effort  This  often  leads  to  acceptance  of  the  first  design,  simply 

* 

because  the  costs  associated  with  redesign  (experimentation)  are  too 
prohibitive. 

Evolutionary  Design.  "Contrary  to  the  Idea  that  a  computer  is 
exciting  because  a  programmer  can  create  something  from  seemingly 
nothing,  our  users  were  shown  that  a  computer  is  exciting  because  It  can  be 
a  vast  storehouse  of  already  existing  Ideas  (models)  that  can  be  retrieved 
and  modified  for  the  user's  personal  needs.  Programming  should  be  viewed 
and  enjoyed  as  an  evolutionary  rather  than  a  revolutlonay  act"  [Goldberg  and 
Ross,  1981:354]  The  Idea  of  an  evolutionary  design  philosophy  Is  very 
applicable  and  appealing  for  the  design  of  cockpit  displays.  The  designer 
creates  the  display  in  a  building  block  fashion  from  sets  of  pre-existing 


Requirements 


25 


TABLE  V 

Prototype  ALC  Functional  Software  Requirements. 


Requirement 

6raphicel  Interaction 

Use  of  graphics  vs.  tent 

Direct  Manipulation 

Draphical  objects  directly 
manipulated  by  the  user. 

Interative  Development 

Evaluation  and  modification 
of  the  design  on  a  continuous 
basis. 

EHperimentatlon 

Design  without  commitment 

Evolutionary  Design 

Build  displays  from  eHlstlng 
parts 

cockpit  objects.  The  'vast  storehouse'  of  objects  already  exists,  the 
designer  simply  assembles  the  objects  to  rorm  the  design. 

in  order  to  support  an  evolutionary  mode  of  operation,  the  prototype 
ALC  should  provide  the  capability  to  save  and  retrieve  cockpit  displays  and 
cockpit  symbology.  The  symbology  should  consist  of  sets  of  standard  cockpit 
instruments,  specialized  cockpit  objects,  and  user  defined  objects.  The  user 
should  also  be  able  to  add,  modify,  and  delete  cockpit  symbols  interactively. 

The  functional  requirements  of  the  ALC  prototype  software  are 
summarized  in  Table  V. 
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Umt  Intwfacg 


The  user  Interface  has  been  touted  as  being  “the  stng'e  most  Important 
consideration  In  designing  any  computer  system*  [Singh,  1 983:55).  It 
functions  as  a  communication  channel  between  the  user  and  the  system.  The 
success  or  failure  of  a  system  often  depends  on  the  users’  acceptance  of  the 
Interface.  It  thus  becomes  Imperative  that  the  user  Interface  be  viewed  as 
an  aid  by  the  user  rather  than  a  hlnderence  [Singh,  1983:551  To  accomplish 
this  objective  several  fundamental  requirements  have  been  levied  on  the 
user  Interface.  These  requirements  are  described  In  the  following 
paragraphs. 

Ease  of  Use.  The  user  Interface  should  be  easy  to  use.  The  prototype 
ALC  is  expected  to  be  used  by  a  variety  of  users  with  differing  backgrounds, 
it  thus  becomes  essential  that  the  user  interface  is  not  tailored  towards 
any  specific  group  of  users.  The  user  Interface  should  not  require  expertise 
in  computer  programming  or  computer  graphics  to  use. 

Minimal  Memorization  To  ensure  ease  of  use,  the  user  interface 
should  minimize  the  commands  the  user  must  remember.  Commands  should 
be  easy  to  understand  and  be  displayed  for  user  selection.  Help  and  memory 
aids  should  also  be  available. 

Easy  to  Learn.  The  user  should  not  have  to  spend  hours  learning  to  use 
the  system  before  becoming  productive.  A  good  criteria  to  use  to  measure 
the  ease  of  which  a  user  can  learn  to  use  a  system  Is  known  as  the 
'10-minute'  rule  [Rubinstein  and  Hersh,  1 98481.  This  rule  states  that  it 
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should  not  take  the  user  longer  than  10  minutes  to  become  familar  and 
proflcent  with  the  system.  If  It  does,  the  user  Interface  should  be 
re-evaluated. 

Apply  Experience.  Experience  acquired  in  one  area  of  the  system 
should  be  applicable  to  other  contexts.  The  user  should  not  have  to  re-leam 
how  to  use  the  system  every  time  he  switches  applications. 

Composition.  All  cockpit  display  composition  should  be  handled  by 
the  user  interface  and  performed  on  the  screen.  Instead  of  performing  the 
design  layout  on  paper  then  translating  it  onto  a  screen,  composing  It  on  the 
screen  first  will  provide  a  direct  mapping  from  design  to  implementation. 
The  designer  builds  the  actual  display  instead  of  a  blueprint  of  It 

Feedback.  Feedback  informs  the  user  what  the  system  Is  doing. 
Feedback  should  be  Immediate,  and  where  appropriate,  visual. 

Supportive  of  the  design  process  The  user  Interface  should 
interact  with  the  user  via  a  problem  space  that  Is  familiar  to  the  user.  In 
the  case  of  the  prototype  ALC,  the  problem  space  is  a  cockpit  display.  The 
user  Interface  should  allow  the  user  to  manipulate  a  representation  of  the 
cockpit  display  as  if  it  were  an  actual  cockpit  display.  The  user  should 
work  directly  on  the  task  (design  process)  without  the  user  interface 
distracting  from  the  process  [Shneiderman,  1983:  631  The  user  Interface 
should  be  transparent  to  the  user.  No  distinction  between  the  screen  and  an 
actual  cockpit  display  should  exist. 

The  user  Interface  requirements  are  summarized  in  Table  VI. 
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TABLE  VI 

User  Interface  Requirements. 


This  chapter  has  presented  the  functional  requirements  for  the  ALC 
prototype.  These  requirements  were  divided  into  three  areas,  hardware, 
software,  and  the  user  interface.  Hardware  requirements  pertain  to  the 
characteristics  of  the  host  system  to  support  the  ALC  prototype.  Four  areas 
were  specifically  addressed,  namely;  display  technology,  Input  devices, 
output  devices,  and  processing  and  storage  capabilities. 

Software  requirements  addressed  the  need  to  follow  sound  software 
engineering  principles  in  the  design  of  the  software.  Specific  functional 
requirements  of  the  ALC  prototype  were  also  outlined.  User  interface 
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requirements  were  presented  separately  from  the  functional  software 
requirements  to  emphasize  their  importance  to  the  ALC  prototype  effort 
Several  key  requirements  were,  outlined.  The  remaining  chapters  of  this 
thesis  apply  the  requirements  defined  In  this  chapter  to  the  design  and 
Implementation  of  the  ALC  prototype. - - 
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III.  System  fltalflp 


The  function  of  the  ALC  prototype  is  to  provide  an  environment  that 
supports  the  creation  and  modification  of  cockpit  layout  designs.  The 
requirements  for  this  environment  were  presented  in  Chapter  2  This 
chapter  provides  a  system  level  design  of  the  ALC  based  on  those 
requirements.  The  design  approach  used  is  f«;l  * scribed,  followed  by  a 
system  design  based  on  that  approach. 

Design  Approach 

This  thesis  employed  the  concepts  associated  with  object-oriented 
design  (OOO)  as  the  primary  philosophy  driving  the  design  of  the  prototype 
ALC  software.  This  particular  design  methology  was  chosen  because  It 
provides  a  direct  means  of  mapping  the  problem  space  onto  a  representation 
of  the  program  space  (i.e.  the  implementation)  [Booch,  1983:401  The 
designer  can  define  and  manipulate  representations  of  entitles  (i.e.  objects) 
in  the  program  space  as  though  they  were  in  the  problem  space.  A 
one-to-one  mapping  Is  maintained  between  the  problem  space  and  the 
Implementation.  The  reader  should  refer  to  Appendix  A  for  a  further 
discussion  of  000  and  Its  relation  to  more  traditional  design  methodologies. 

Object-oriented  design  starts  by  restating  the  problem  in  terms  of  its 
requirements.  This  Is  then  followed  by  a  conceptual  implementlon  in  which 
object  and  associated  operations  are  identified.  Objects  being  the  actual 
entities  that  populate  the  problem  space  and  operations  being  the  actions 
that  manipulate  the  objects.  Once  identified,  the  objects  and  corresponding 

System  Design  3 1 


operations  are  than  implemented  (l.e.  mapped  to  a  software  realization). 
These  Implementation  details  are  not  addressed  in  the  design  process,  but 
rather  discussed  In  Chapter  7. 

SyatamDealgn 

As  stated  previously,  the  ALC  prototype  Is  intended  to  be  a  highly 
interactive  graphics  system  capable  of  supporting  the  creation  and 
modification  of  cockpit  layout  designs.  To  accomplish  this  goal,  several 
operational  requirements  were  levied  on  the  prototype  ALC.  These 
requirements  addressed  the  need  of  the  prototype  ALC  to  support 

-  a  user  interface  that  Is  supportive  of  the  design  process, 

-  the  dynamic  creation  and  modification  of  cockpit  layouts, 

-  the  dynamic  creation  and  modification  of  cockpit  symbology,  and 

-  an  archival  mechanism  for  storage  and  retrieval  of  cockpit 
layouts  and  symbology  for  future  use. 

These  requirements  can  be  realized  as  four  separate  but  interrelated 
functional  components:  1)  the  user  interface,  2)  Layout  Editor,  3)  Symbol 
Editor,  and  4)  a  Librarian.  The  specific  functions  that  each  of  these 
components  perform  will  be  addressed  in  later  chapters  ( 4, 5,  and  6).  This 
chapter  serves  to  identify  these  four  major  functional  components  and 
briefly  to  describe  their  interaction. 

The  Interaction  among  these  components  is  best  viewed  by  using  a 
layered  approach.  Figure  3.  illustrates  the  interrelationship  of  these 
components  based  on  this  approach.  Each  layer  represents  the  relative 
degree  of  interaction  among  the  components.  Only  those  components  that 
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Figure  3.  Prototype  ALC  System  Structure. 

share  a  common  boundary  can  interact  directly  with  each  other.  A 
description  of  each  layer  follows. 

The  moat  visible  layer  of  the  structure  Is  the  user  interface.  This  is 
the  only  layer  with  which  the  user  directly  interacts.  All  user  requests 
and/or  system  responses  are  conveyed  through  this  layer.  The  user 
Interface  maintains  a  consistent  and  familiar  boundary  between  the  user 
and  the  other  layers. 

The  next  layer  In  the  structure  contains  the  Layout  and  Symbol  editors. 
The  Layout  Editor  supports  the  creation  and  modification  of  cockpit  layout 
designs  while  the  Symbol  Editor  supports  the  creation  and  modification  of 
individual  cockpit  symbols.  Both  editors  are  directly  accessible  from  the 
user  interface  and  both  can  directly  access  the  Librarian. 

The  last  layer,  the  Librarian,  serves  as  a  repository  for  all  cockpit 
layout  designs  and  cockpit  symbology.  The  Librarian  can  only  be  accessed  by 
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on#  of  tht  two  editors.  The  user  cannot  directly  access  the  Lfbrsrian 
without  invoicing  an  editor  first  This  prevents  the  user  from  unwittingly 
corrupting  the  cockpit  layouts  or  symbology. 

The  detailed  design  considerations  for  each  layer  will  be  presented  in 
the  following  chapters. 

Summwy 

The  design  of  the  prototype  ALC  software  is  based  on  an 
object-oriented  design  (OOO)  approach.  Basically  000  involves, 

-defining  the  problem, 

-  identifying  the  objects  in  the  problem  domain,  and 

-  Identifying  the  operations  on  those  objects. 

This  approach  was  then  used  to  derive  a  system  level  design  of  the  ALC 
prototype.  Four  system  components  (objects)  were  identified.  They  were 
the  user  interface,  Layout  Editor,  Symbol  Editor,  and  the  Librarian.  The 
interrelationship  of  these  components  was  illustrated.  The  following 
chapters  ( A ,  5,  and  6)  apply  this  design  method  to  each  of  the  system 
components  identified,  providing  detailed  design  considerations  for  the 
prototype  ALC  software. 
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JL3L  Uatr  Interface 


The  most  visible  aspect  of  the  ALC  prototype  Is  the  user  Interface 
(Figure  4).  It  is  the  medium  through  which  all  user  actions  and  system 
responses  are  handled.  The  style  In  which  the  Interaction  Is  conducted  can 
directly  Influence  the  user  perception  and  acceptance  of  the  system.  It  thus 
becomes  imperative  that  the  user  Interface  Is  based  on  Ideas  or  concepts 
that  enhance  the  design  process.  The  user  Interface  should  be  viewed  as  an 
aid  rather  than  a  hindrance.  The  discussion  of  the  design  of  the  prototype 
ALC  user  Interface  Is  divided  Into  two  sections.  The  first  section  describes 
key  design  considerations  that  were  used  during  the  Interface  design  phase. 
The  second  section  presents  the  realization  of  these  considerations 
embodied  in  the  actual  user  interface  components. 

dmiqd  mum 

Traditionally,  computer  systems  were  designed  to  give  the  user  the 
utmost  amount  of  computer  power.  Little,  If  any,  attention  was  given  to 
user  interface  Issues.  As  a  result,  users  were  often  overwhelmed  with 
complex  and  terse  commands.  Initial  user  productivity  suffered  due  to  the 
level  of  training  required  to  become  proficient  in  system  use.  Procedures 
and  concepts  learned  in  one  section  of  the  system  seldom  carried  over  to 
others  [Harslem,1984:l05].  Users  were  often  confronted  with  systems  that 
were  cumbersome,  frustrating,  and  difficult  to  use  [Bertlno,  1983:38]. 
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Figure  4  User  Interface  Layer. 


Recent  trends  in  system  development,  most  noticeably  the  Xerox  Star 
[Smith  at  at.,  1982]  and  Apple  Lisa  and  Macintosh  [Apple  Computer  Inc., 
1985],  have  shifted  the  attention  given  to  the  user  interface  issues  to  the 
forefront  of  the  design  process.  The  user  Interface  is  no  longer  considered 
an  'add-on'  component,  but  viewed  as  the  single  element  that  binds  the 
system  and  the  user  into  a  cohesive  whole. 

To  ensure  a  useful  interface,  several  design  considerations  were 
followed.  These  design  considerations  were: 

-  Familiar  User's  Conceptual  Model 

-  Supportive  Dialogue  Mode 

-  Visual  Fidelity 

-  Consistency 

Familiar  Users  Conceptual  Model.  A  user's  conceptual  model 
defines  the  set  of  concepts  that  explain  the  behavior  of  the  system  [Smith 
et.  al.t  1982:248].  Specifically  the  conceptual  model: 
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(1)  Mints  the  general  form  of  the  set  of  capabilities 
perceived  by  the  user. 

(2)  gives  the  philosophy  behind  the  system.  Ideally  in  a 
manner  that  the  user  Is  both  familiar  with  and 
comfortable  with 

(3)  develops,  In  the  user's  mind,  a  framework  of  the 
system  which  the  user  should  be  able  to  associate 
with  and  which  he/sht  can  learn,  comprehend  and  use 

to  interpret  the  system's  behavior.  [Bertlno,1985: 38-39) 

Newman  and  Sproull  have  likened  the  conceptual  model  to  that  of  a 
grammar  for  a  foreign  language.  Their  premise  being,  like  a  foreign 
grammar  that  defines  the  rules  of  communication,  the  conceptual  model 
defines  the  way  the  user  will  perceive  the  Interaction  with  the  system. 
Fluent  communication  Is  achieved  only  when  the  model  or  the  grammar 
becomes  second  nature.  The  model  Is  not  perceived  as  a  guiding  influence 
but  rather  as  being  ‘Installed1  In  the  mind  of  the  user  [Newman  and  Sproull, 
1979:4481 

The  development  of  the  conceptual  model  can  significantly  Influence 
the  design  of  the  user  Interface.  There  are  two  basic  approaches  to  the 
development  of  conceptual  models,  Innovation  and  emulation  [Bert1no,1985: 
39).  innovation  models  exploit  new  types  of  representational  possibilities 
in  the  user  interface.  They  introduce  new  ways  of  thinking  about  situations 
and  new  procedures  for  dealing  with  them.  Emulation  models,  on  the  other 
hand,  emulate  the  current  activities  employed  by  the  user  in  an  existing 
system.  Familiar  concepts,  knowledge,  and  procedures  are  incorporated  Into 
the  user  interface.  This  usually  makes  the  model  more  Intuitive  and  easier 
to  learn. 
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The  aL  J  prototype  takes  an  emulation  approach  to  the  development  of 
Its  conceptual  model.  Emulating  the  current  design  process,  the  conceptual 
model  Incorporates  as  Its  central  theme  the  Idea  of  constructing  cockpit 
layouts  In  a  building  block  fashion.  The  building  blocks  nre  pre-defined  sets 
of  cockpit  components  that  actually  represent  those  being  used  in  the  design 
process.  The  procedures  used  and  the  cockpit  components  remain  familiar  to 
the  user.  The  user  Is  not  required  to  develop  a  new  mindset  to  Interact 
effectively  with  the  user  Interface. 

A  convenient  way  of  representing  such  a  model  Is  via  the  use  of  an 
object-oriented  paradigm.  The  model  is  viewed  as  a  set  of  objects  (cockpit 
components)  and  a  set  of  operations  (selection  and  placement)  that 
manipulate  the  objects  and  Its  environment  (cockpit  layout)  [Newman  and 
Sproull,  1979:448;  Hearn  and  Baker,  1986:3301  Models  based  on  such  a 
paradigm  provide  an  effective  means  of  representing  the  problem  space.  As 
Cox  points  out: 

Objects  are  natural  metaphors  for  model  building  In  that 
each  Is  a  capsule  of  state  and  behavior,  a  virtual  machine  that 
can  be  used  as  a  computer-based  executable  instance  of  a 
corresponding  entity  in  the  user's  problem  domain.  This 
potential  for  close  correspondence  between  computer  and 
problem  domain  can  be  useful  In  building  inexpensive, 
understandable  systems  [Cox,  1984:571 

Such  models  allow  the  user  to  Interact  directly  with  the  objects  of 
Interest  without  concern  for  the  actual  object  Implementation  [Arora  et.  al., 
1985:465].  The  user  is  not  forced  to  interact  with  the  system  In  computer 
terms  (thus  avoiding  detailed  procedural  specifications)  [Foley  and  McMath, 
1986: 16]  but  rather  interacts  at  the  display  level,  where  ideas  and  concepts 
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can  be  formalized  and  tried  (Gltnert  and  Tanfmoto,  1984:111.  The  objects 
and  associated  permissible  actions  become  the  Interface  [Arora  et.  al., 
1985:4651  The  distinction  between  de.  gn  and  implementation  fades. 

The  perceived  ability  to  interact  directly  with  the  objects  lends  itself 
naturally  to  the  cockpit  design  process.  Objects,  In  this  case,  rrpnifest 
he’vselves  as  cockpit  entitles.  Operations  are  provided  that  allow  direct 
spatial  manipulation  of  individual  cockpit  entitles  and  direct  spatial  and 
structural  manipulation  of  Individual  cockpit  entity  attributes.  The  actual 
implementation  of  each  cockpit  entity  is  hidden  from  the  designer,  only  the 
entities  behavior  is  observable. 

Accepting  an  object-oriented  viewpoint  allows  the  designer  to 
visualize  the  interface  as  a  virtual  cockpit  display.  Virtual  In  the  sense  that 
a  multitude  of  cockpit  display  types,  consisting  of  many  cockpit  entitles, 
can  be  created  via  the  same  Interface  and  methodology.  The  methodology 
simply  being  the  selection  and  placement  of  cockpit  entitles  on  the  cockpit 
display.  Such  a  model  provides  the  designer  a  familiar  and  workable 
environment  for  cockpit  display  generation. 


There  are  two  basic  dialogue  modes: 
user- Initiated  and  system- Initiated  [Singh  et.  al.,  1 983:561  The  choice  of 
which  dialogue  mode  to  use  depends  on  the  Intended  audience  and  the  type  of 


interaction  desired. 


User-initiated  dialogues  require  the  user  to  issue  commands  in  order  to 
accomplish  a  task.  The  user  is  responsible  for  memorizing  command  syntax 
and  Issuing  commands  at  the  appropriate  time  and  in  proper  sequence.  Little 


if  any  prompting  is  performed  by  the  Interface.  This  mode  of  dialogue 


provides  the  greatest  degree  of  flexibility  but  places  an  extra  burden 
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(command  memorization)  on  the  user.  It  Is  best  suited  for  expert  users  of  a 
system  (Hearn  and  Baker,  1986:3331 

System- Initiated  dialogues  require  almost  no  memorization.  They 
display  all  relevant  information  pertaining  to  the  task  at  hand  and  prompt 
the  user  for  command  selection.  They  are  best  suited  for  novice  users  [Hearn 
and  Baker,  1986:333]  since  they  guide  the  user  through  the  command 
selection  and  sequencing.  This  type  of  dialogue  relies  on  recognition  of 
commands  rather  than  recall. 

A  system-initiated  dialogue  was  chosen  as  the  dialogue  method  for  the 
prototype  ALC  user  Interface.  System-initiated  dialogues  are  better  suited 
than  user-initiated  dialogues  for  the  user  interface  requirements  identified 
in  Chapter  2.  Specifically,  a  system-initiated  dialogue  approach  satisfies 
the  requirements  for  ease  of  use,  minimal  memorization,  and  ease  of 
learning. 

System-initiated  dialogues  tend  to  be  more  novice-oriented  than 
user-initiated  dialogues  (Hearn  and  Baker,  1986:3331  They  assume  little,  If 
any,  prior  technical  expertise  on  the  part  of  the  user,  lending  themselves 
naturally  for  use  by  a  large  audience.  A  prime  requirement  of  the  ALC  is 
that  It  be  usable  by  a  variety  of  users,  with  different  technical  backgrounds. 
It  is  essential  that  the  user  Interface  is  not  tailored  toward  any  specific 
group. 

System-Initiated  dialogues  minimize  the  amount  of  memorization 
required  by  the  user.  All  objects  and  commands  of  interest  are  displayed 
and  available  for  selection.  The  user  is  not  required  to  remember  command 
syntax  or  command  sequencing.  Relieving  the  user  of  this  burden  directly 
Impacts  the  quality  of  the  thinking  (l.e.  design)  process. 
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Studies  have  shown  that  ‘conscious  thought  deals  with  concepts  In 
short-term  memory  and  the  capacity  of  short-term  memory  Is  limited" 
[Smith  et.  al,  1982:2601  By  displaying  available  commands,  short-term 
memory  is  relieved  of  the  burden  of  command  recall  and  syntax  formulation. 
Thinking  becomes  easier  and  more  productive  as  the  user  is  permitted  to 
concentrate  on  the  creative  aspects  of  the  design  process  without  being 
burdened  by  the  dialogue  (Smith  et  al.,  1982.2601  The  dialogue  becomes  a 
mechanical  device  for  Issuing  actions  without  impacting  the  conscious 
thought  (design)  process  [Bertlno,  1 985: 501 

Learning  is  also  eased  by  system-initiated  dialogues.  Learning  in  this 
context,  refers  to  the  time  It  takes  a  user  to  become  proficient  In  a 
system's  use,  in  order  to  perform  productive  work.  This  is  not  to  Imply  that 
the  users  needs  to  be  proficient  In  all  aspects  or  system  use;  they  seldom 
are  [Rubinstein  and  Hersh,  1984:81  But  rather,  the  user  needs  to  know  only 
the  subset  of  the  system  that  directly  influences  the  task  at  hand.  The  time 
it  takes  to  learn  these  capabilities  should  be  mlntmtal.  A  general  rule  of 
thumb,  known  as  the  *10  minute'  rule,  attempts  to  limit  this  learning  time 
to  ten  minutes.  If  it  takes  longer  than  ten  minutes,  the  interface  should 
probably  be  re-evaluated  and  perhaps  redesigned. 

System-Initiated  dialogues  provide  a  viable  means  of  satisfying  the  ten 
minute  constraint.  Information  needed  to  converse  with  the  interface  is 
always  displayed,  relieving  the  user  of  the  burden  of  command  syntax  recall. 
The  user  can  experiment  with  commands  and  options  immediately  without 
worrying  about  command  syntax  or  key-ln  errors.  Attention  Is  focused  on 
system  understanding  instead  of  being  divided  among  tasks.  A  semantic 
understanding  of  the  system  (concepts  and  functionality)  is  gained  rather 
than  a  syntactic  (detail)  (Shnelderman,  1983:651 
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System-Initiated  dialogues  also  aid  In  regaining  proficiency  In  a 
system  after  an  extended  absence.  It  Is  desirable  to  have  the  user  'up  to 
speed*  as  soon  as  possible.  Since  the  user  has  already  developed  a  semantic 
understanding  of  the  system  and  Its  commands,  the  time  required  to  become 
proficient  will  usually  be  less  than  If  the  system  were  based  on  a 
user-initiated  dialogue.  The  reason  being,  syntactic  knowledge  Is  "volatile 
in  memory  and  Is  easily  forgotten  if  not  frequently  used*  [Shnelderman, 
1983:651  Semantic  knowledge  tends  to  be  more  system  independent  and 
once  "acquired  through  general  explanation,  analogy,  and  example,  is  easily 
anchored  in  familiar  concepts  and  is  therefore  stable  In  memory" 
(Shnelderman,  1983:651  The  stability  of  semantic  knowledge  allows  a  user 
to  regain  proficiency  faster  and  retain  It  longer. 

Visual  Fidelity.  Visual  fidelity  or  "What  You  See  is  What  You  Get" 
refers  to  the  ability  of  representing  a  rendition  of  the  actual  output  on  the 
display  screen  [Smith  et  at.,  1982:2641  In  this  application  area  the  display 
screen  is  the  computer  display  that  the  user  sees,  and  the  output  Is  an 
actual  cockpit  display  that  the  pilot  sees. 

Visual  fidelity  provides  the  user  with  a  means  of  directly  Interacting 
with  the  problem  space;  seemingly  by-passing  the  user  interface 
[Shneldermanm,  1983:631  "The  user  operates  directly  on  the  data  in  a  form 
convenient  to  him  (Is.  cockpit  objects),  not  one  Imposed  by  the  computer 
(is  cods)'  [Harslem,  1984:103]  (Italic  phrases  added  by  author).  Cockpit 
layouts  are  composed  directly  on  the  display  screen  and  mapped  directly  to 
the  target  cockpit  display.  The  user's  view  of  the  display  screen  and  the 
cockpit  display  are  inseparable. 
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Consistency.  Consistency  In  the  user  Interface  allows  the  user  to 
Interact  with  various  parts  of  the  system  without  having  to  change  the 
method  of  Interaction.  The  user  learns  one  method  of  Interaction  as  opposed 
to  several  A  consistent  Interface  reduces  the  amount  of  re- learning  that 
user  must  perform  while  switching  between  applications  [Harslem, 
1984:1051  It  allows  the  skills,  procedures,  and  concepts  acquired  in  one 
section  of  the  system  to  be  applied  equally  to  other  sections  [Marcus, 
1984:241 

The  prototype  ALC  promotes  consistency  by  providing  a  single  user 
Interface  for  all  sections  of  the  system.  Commands  are  generic  in  nature, 
thus  allowing  for  a  small  set  of  commands  to  be  used  throughout  The 
extraneous  application-specific  semantics  of  a  command  are  stripped  away 
allowing  the  user  to  deal  directly  with  Its  underlying  meaning  [Smith  et.  al, 
1982:  2681  The  actual  physical  interaction  (object  positioning  and 
selection,  command  selection)  is  performed  via  a  mouse.  The  keyboard  is 
used  exclusively  for  textual  Input  only. 

Table  VII  summarizes  the  design  considerations  which  guided  the 
design  of  the  prototype  ALC  user  Interface. 

UatcInUrtice  Cotimonenta 

Based  on  the  design  considerations  discussed  above  and  the  user 
interface  requirements  presented  in  Chapter  2,  the  user  interface  design  of 
the  prototype  ALC  can  be  satisfied  by  providing  five  components,  the 
keyboard,  a  mouse,  windows,  command  bottons,  and  menus.  A  description  of 
each  component  and  Its  associated  functions  follow. 
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Table  VII 

User  Interface  Design  Criteria 


Criteria 

Conceptual  Model 

Emulation-Mode,  models 
the  current  design  process 

Dielogue  Mode 

System-initiated 

Ultuel  Fidelity 

mat  vou  see  is  mat 

Vou  6et* 

Consistency 

Single  User  Interface 

Ueneric  Commands 

«frl 
'  •■*1 


J 

:Sl 

‘  I  ‘ 

si 


Keyboard.  The  keyboard  Is  an  input-only  device  used  exclusively  for 
textual  input.  Special  characters,  control  character  sequences,  or  command 
sequences  are  Ignored  by  the  user  interface.  The  user  interface  only 
recognizes  Input  from  the  keyboard  when  a  request  Is  made  for  textual  data 
Mouse,  a  mouse  is  used  as  the  primary  physical  means  of  Interacting 
with  the  interface.  The  mouse  serves  as  an  extension  (prosthesis)  of  the 
user,  allowing  the  user  to  point  to  a  location  on  the  screen  and  make  a 
selection. 

Most  mice  available  today  support  a  number  of  buttons  for  object 
selection.  Often  an  application  will  assign  different  functions  to  these 
buttons.  The  prototype  ALC  user  Interface  treats  all  buttons  on  a  mouse  as 
a  single  pick  device.  No  matter  which  button  Is  pressed,  the  result  Is  a 
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simple  pick/selection  action.  Restricting  the  function  of  the  buttons  aids  in 
the  portability  of  the  Interface  and  prevents  the  user  from  making  a  mistake 
(i.e.  pressing  the  wrong  button). 

Window.  Windows  are  rectangular  regions  on  the  display  screen  which 
serve  as  the  focal  point  for  user  interaction.  The  user  interface  supports 
three  types  of  windows,  applications,  option,  and  dialogue. 

Application  windows  provide  a  medium  for  viewing  and  manipulating 
objects.  All  objects  (cockpit  displays  and  symbols)  that  the  user  can 
manipulate  are  displayed  within  application  windows. 

Option  windows  display  representations  of  objects  that  are  available 
for  selection.  An  active  option  Is  indicated  by  highlighting  the  option 
selected. 

Dialogue  windows  serve  a  multi-purpose  role.  First,  they  provide  a 
standard  means  of  requesting  additional  information  pertinent  to  the 
execution  of  a  command  (i.e.  prompting  for  file  name  on  a  'SAVE* ).  Second, 
they  serve  as  a  means  of  confirming  the  intention  of  the  user  (i.e.  queries  to 
insure  the  user  really  wants  to  delete  a  file).  Lastly,  the  dialogue  window 
is  used  to  Inform  the  user  of  any  error  conditions. 

Application  and  option  windows  are  classified  as  'modeless'  windows, 
meaning  that  their  presence  does  not  require  a  response  by  the  user.  The 
user  is  free  to  Interact  with  these  windows  as  he  chooses.  On  the  other 
hand,  the  dialogue  window  is  known  as  a  'modal'  window.  This  window,  when 
displayed  requires  the  next  user  response  to  be  directed  toward  It.  The  user 
is  forced  Into  a  response  mode.  The  user  must  satisfy  the  window  prompt 
before  futher  processing  can  take  place.  The  mouse  and  the  keyboard  are 
dedicated  to  the  dialogue  window. 
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Command  Buttons.  Command  buttons  act  as  scratn  function  kays.  Thoy 
serve  as  a  means  of  issuing  commands  to  the  system.  Only  those  commands 
that  are  pertinent  to  the  current  processing  are  displayed. 

tjsou.  Menus  serve  as  another  medium  for  command  invocation.  Menus 
consist  of  logically  related  commands,  herein  refered  to  as  menu  items. 

The  user  interface  supports  what  are  known  as  ‘pop-up*  menus.  The 
term  pop-up  comes  from  the  way  these  menus  are  activated,  initially,  the 
user  only  sees  a  menu  title  on  the  screen.  If  a  title  is  selected,  the  menu 
items  associated  with  that  title  'pop-up'  underneath  it  The  cursor  can  then 
be  moved  over  the  desired  Item  for  selection.  When  a  selection  is  made  or 
the  cursor  Is  moved  outside  the  menu  region,  the  menu  disappears. 

Pop-up  menus  force  the  user  Into  a  response  mode  only  when  they  are 
activated.  At  which  time,  the  interface  directs  all  user  actions  toward 
menu  selection.  The  user  is  required  to  make  a  selection  or  cancel  the  menu 
activation  by  moving  the  cursor  outside  the  menu  region.  All  other  user 
actions  are  Ignored  when  a  menu  is  activated.  Otherwise,  pop-up  menus 
Impose  no  restrictions  on  user  actions. 

Summary 

The  user  interface  has  often  been  considered  the  "most  difficult  and 
the  least  understood  part  of  interactive  systems'  [Singh  et.  al.,  1983:551 
This  chapter  has  presented  the  user  Interface  In  two  parts.  The  first  part 
described  the  design  considerations  that  were  adhered  to  In  conceptual 
design  of  the  Interface.  The  second  part  described  the  actual  components 
that  constitute  the  physical  structure  of  the  Interface. 
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M  Editors 


The  ALC  prototype  Incorporates  two  distinct,  yet  similar,  graphic 
editors  to  enhance  the  design  process  (Figure  5).  The  Layout  Editor,  directly 
supports  the  creation  and  modification  of  cockpit  displays.  The  second 
editor,  the  Symbol  Editor,  supports  the  creation  and  modification  of 
individual  cockpit  symbols.  The  editors  are  similar  In  the  methodologies 
they  employ,  but  differ  on  the  view  of  the  design  process  they  present  to  the 
designer.  The  Layout  Editor  allows  the  designer  to  view  and  manipulate  a 
design  as  a  collection  of  spatially  arranged  cockpit  symbols,  while  the 
Symbol  editor  allows  the  designer  to  view  and  manipulate  the  Internals  of 
individual  cockpit  symbols.  The  similarities  and  differences  of  these  two 
editors  are  presented  In  this  chapter'. 


Currently,  cockpit  display  construction  starts  with  the  design  and 
analysis  of  the  cockpit  layout  on  paper.  When  complete,  the  design  is 
transferred  to  software  experts  for  translation  Into  code.  Depending  on  the 
complexity  of  the  design  and  the  amount  of  new  code  needed  to  be  generated, 
the  designer  may  not  realize  the  Implementation  of  the  design  for  weeks  or 
months  after  submission.  To  make  matters  worse,  modifications  to  the 
Implemented  design  could  entail  further  delays.  This  process  is  very  time 
consuming  and  programmer- intensive.  The  designer's  productivity  is  at  the 
mercy  of  the  software  development  process. 
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Figures.  Editor  Layer. 


To  combat  this  problem,  the  ALC  prototype  incorporates  two  types  of 
editors,  the  Layout  Editor  and  the  Symbol  Editor.  Both  editors  are  graphics 
based  and  object-oriented  in  nature.  Their  function  is  to  make  the  design 
and  analysis  phase  a  more  productive  and  enjoyable  task  by  supporting  the 
bulk  of  the  design  activity  in  a  responsive,  Interactive  graphics 
environment  The  goals  of  these  editors  are  to  free  the  designer  from  the 
tedium  of  designing  cockpit  displays  on  paper  and  reduce  the  need  for 
software  experts  for  design  Implementation.  To  accomplish  this,  the  editors 
promote  the  interactive  design  of  cockpit  displays  and  symbology  from 
pre-deftned  classes  of  cockpit  symbols.  The  Layout  Editor  supports  the 
design  of  cockpit  displays,  while  the  Symbol  Editor  supports  cockpit 
symbology  construction. 
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Although  both  odttors  ptrfortn  different  tasks,  thsrs  art  four  common 
raqulrsmants  that  both  must  support: 

-  Graphic  Interaction, 

-  Iterative  Development, 

-  Evolutionary  Design, 

-Experimentation. 

finable  Interaction.  The  process  of  designing  a  cockpit  display  Is  a 
spatially  oriented  activity.  It  relies  heavily  on  the  use  of  graphic  Images  for 
representing  cockpit  and  real-world  objects.  Both  editors  exploit  the  use  of 
graphics  as  the  main  medium  of  Interaction.  All  editing  is  performed  on 
graphic  entitles  versus  the  use  of  textual  information.  The  editors  work 
directly  in  the  mode  most  natural  to  the  design  process,  graphics. 

itantiw  Development  iterative  development  Is  a  process  by  which 
designs  are  continuously  evaluated  and  modified  to  satisfy  design 
requirements.  Both  editors  take  on  an  active  role  In  supporting  this 
requirement  Both  editors  assist  the  user  by  providing  the  facility  for 
creating  new  designs,  modifying  existing  designs,  and  supporting  the  rapid 
generation  of  alternative  designs. 

The  primary  function  of  both  editors  Is  the  creation  of  new  cockpit 
designs.  Designs  are  created  by  selecting  and  arranging  (Inserting) 
pre-deflned  objects  on  the  display  screen  to  satisfy  a  design  requirement. 
Besides  Inserting  objects,  both  editors  also  support  object  deletion  and 
repositioning.  Final  designs,  or  work  In  progress,  can  be  saved  for  future  use 
or  discarded. 


Editor  Design 


49 


In  addition  to  creating  new  designs,  the  editors  also  support  the 
capability  of  modifying  existing  designs  or  generating  alternative 
representations  of  existing  designs.  Modifying  a  design  usually  involves  the 
inserting  or  deleting  objects  from  a  layout,  then  saving  the  result  This  in 
affect  destroys  the  original  design.  Creating  an  alternative  design 
representation  Is  a  non-destructive  editing  procedure.  The  original  destgn 
serves  as  a  template  from  which  objects  can  be  added  or  deleted.  The 
modified  original  is  saved  as  a  different  destgn,  leaving  the  original  design 
intact 

Evolutionary  Design.  The  premise  behind  an  evolutionary  design 
approach  is  to  eliminate  the  practice  of  'reinventing  the  wheel'  every  time  a 
design  is  created.  To  accomplish  this,  the  ALC  prototype  promotes  the 
creation  of  designs  from  pre-existing  sets  of  cockpit  symbols.  Designs  can 
then  be  constructed  in  a  building  block  fashion  from  these  symbols.  The 
editors  directly  support  this  methodology  by  allowing  the  user  to  manipulate 
these  symbols  as  discrete  entitles;  they  can  be  selected,  positioned,  and 
deleted  from  the  display.  The  user  never  deals  with  anything  conceptually 
simpler  than  an  object 

Experimentation.  Both  editors  actively  support  experimentation.  They 
provide  the  designer  with  the  capability  or  experimenting  with  different 
design  layouts  without  committing  the  work  to  a  final  destgn.  To  support 
experimentation,  both  editors  allow  the  user  to  undo  the  last  operation 
performed,  erase  the  entire  design,  and  restore  the  design  to  Its  original 
form. 
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fimcUonal  aimllarniti 


The  similarities  of  the  two  editors  are  best  delineated  by  Identifying  the 
functional  areas  that  comprise  each  editor.  This  Is  conveniently  done  by 
illustrating  the  generic  display  form  common  to  both  editors  (Figure  6).  The 
display  consists  of  three  functional  areas;  the  option  area,  the  work  area, 
and  the  command  area. 

The  option  area  of  the  display,  maintains  a  list  the  objects  that  are 
currently  available  for  selection.  The  objects  are  ptctortally  displayed  In 
miniature  form.  The  process  of  object  selection  is  identical  for  both  editors. 

Objects  are  selected  by  positioning  the  cursor  over  the  desired  object 
and  pressing  a  mouse  button.  The  selected  object  is  'made  active'  and  is 
highlighted  to  indicate  selection.  The  next  ttme  the  cursor  is  within  tiv  work 
area  and  a  mouse  button  pressed,  the  selected  object  will  be  drawn.  The 
selected  object  remains  active  until  another  object  Is  selected  or  the  work 
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area  is  cleared  This  allows  the  user  to  add  multiple  Images  of  the  selected 
object  on  to  the  work  area  without  having  to  reselect  the  object  each  time. 

The  second  functional  area  of  the  display  Is  the  work  area.  This  area 
serves  as  the  designer's  chalkboard  Designs  are  constructed  and  displayed 
within  this  region.  Within  this  area  the  user  can  perform  three  basic 
functions;  object  Insertion,  object  deletion,  and  object  repositioning.  The 
process  of  Insertion  Is  unique  to  the  editor  used  and  will  be  cover  In  detail  in 
later  sections.  Deletion  and  repositioning,  however,  are  Identical  to  both 
editors  and  will  be  addressed  here. 

Deletion  Is  the  process  of  removing  an  object  from  the  work  area. 
Objects  are  removed  In  a  manner  analogous  to  option  selection.  First  the 
object  Is  selected,  then  the  Trash'  button  Is  selected  This  cause  the 
selected  object  to  be  removed  from  the  work  area  and  the  work  area  to  be 
redrawn 

Repositioning  Is  also  similar  to  option  selection  First  the  object  is 
selected  within  the  work  area,  then  the  cursor  is  repositioned  and  a  mouse 
selection  Is  made.  The  selected  object  is  erased  from  Its  original  location 
and  redrawn  at  the  new.  If  the  new  location  Is  outside  the  work  area  the 
object  remains  in  its  original  location 

To  aid  in  the  deletion  and  repositioning  process,  an  extent  box  is  drawn 
around  the  selected  object  The  extent  box  serves  to  Identify  exactly  which 
object  Is  selected  This  Is  helpful  when  multiple  objects  overlay  each  other, 
or  are  positioned  in  close  proximity  to  each  other.  The  user  is  not  left 
guessing  which  object  was  actually  selected,  but  can  directly  determine  by 
visual  inspection.  Besides  identifying  an  object,  the  extent  box  also  tracks 
the  cursor  while  Inside  the  work  area.  This  provides  the  user  with  a  spatial 
reference  for  repositioning. 
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The  third  area  of  the  editor  displays  is  the  command  section.  All 
commands  that  effect  the  editor  are  listed  here.  Commands  are  displayed  as 
command  buttons.  The  user  selects  a  command  by  positioning  the  cursor  over 
the  desired  button  and  pressing  a  mouse  button.  The  editors  interpret  the 
selection  and  perform  the  desired  action. 

There  are  several  commands  that  are  identical  to  both  editors.  These 
commands  are  Hated  below  with  an  accompanying  description  Commands 
unique  to  an  editor  will  be  presented  under  that  editor's  description 

New:  Resets  the  editor  by  clearing  the  current  design  If  the  current 
design  Is  not  saved  prior  to  Issuing  this  command,  the  editor 
prompts  to  save  It 

Old:  Retrieves  an  existing  design  If  the  current  design  Is  not  saved 

prior  to  issuing  this  command,  the  editor  prompts  to  save  It 

Save:  Saves  the  current  design  If  this  Is  a  new  design  the  user  Is 
prompted  for  a  title,  otherwise  the  design  is  saved  under  Its 
original  title. 

SaveAr.  Saves  the  current  display  under  a  different  title. 

Undo:  Undoes  the  last  operation  performed  In  the  work  area. 

Clear  Clears  the  work  area  and  de-actlvates  the  currently  selected 
object 

Revert:  Restores  the  current  design  to  Its  original  content.  If  the 
current  design  is  new  then  this  command  has  no  effect 

Quit:  Terminates  the  editing  session  and  exits  the  user  from  the 
environment 

Although  the  editors  are  similar  in  many  respects,  there  are  Important 
differences  that  distigulsh  the  two  editors.  These  differences  are 
presented  in  the  following  sections. 
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Figure  7.  Typical  Layout  Editor  Format 


Lay-out.  Editor 

w  The  Layout  Editor  serves  as  the  sole  means  of  creating  and  modifying 

cockpit  layout  designs.  Layouts  are  constructed  In  a  building  brock  fashion 
from  sets  or  predefined  cockpit  components  or  symbols.  The  user  simply 
selects  the  desired  component,  from  an  available  option  list,  and  places  It 
on  the  cockpit  layout  A  typical  format  of  the  Layout  Editor  Is  provided  In 
Figure  7.  The  functional  capabilities  unique  to  the  Layout  Editor  are 
discussed  in  the  following  paragraphs. 

The  option  area  of  the  Layout  Editor  differs  from  the  Symbol  Editor  In 
one  major  respect;  namely,  the  types  of  objects  displayed  for  selection. 
Because  the  Layout  Editor  Is  Intended  to  be  used  to  create  a  multitude  of 
different  cockpit  layouts,  the  objects  available  for  selection  will  vary  with 
the  design  being  constructed 
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The  Layout  Editor  handles  object  Insertion  differently  than  the  Symbol 
Editor.  Basically^  object  Insertion  Is  based  on  a  technique  known  as 
'dragging'.  Dragging  Is  an  interactive  technique  for  dynamically  moving  an 
object  under  cursor  control.  Objects  selected  In  the  option  area  are 
'dragged*  into  the  work  area,  positioned,  then  inserted  by  pressing  a  mouse 
button.  To  aid  the  user  in  object  placement,  an  extent  box,  defining  the 
object's  size,  is  drawn  around  the  cursor.  The  extent  box  tracks  the  cursor 
as  it  Is  moved  around  inside  the  work  area.  When  the  object  Is  Inserted, 
the  extent  box  Is  removed. 

The  Layout  Editor  supports  two  unique  commands;  namely. 

Info:  Displays  a  narrative  of  the  selected  object  This  command  Is 

Ignored  by  the  editor  If  there  Is  no  object  selected. 

Set  Up:  Provides  a  means  of  accessing  the  cockpit  symbology  libraries. 
The  user  is  provided  with  the  options  to  select  new  classes  of 
symbols,  remove  current  classes  from  the  display,  or  Invoke  the 
Symbol  Editor  to  modify  a  cockpit  symbol. 

Symbol  Editor 

The  Symbol  Editor  provides  the  user  with  a  means  of  creating  and 
modifying  cockpit  symbology.  Symbols  are  created  In  a  manner  analogous  to 
cockpit  layouts,  except  the  range  of  options  to  ctoose  from  is  limited  and 
each  object  has  Its  own  unique  method  for  being  Inserted  into  the  work  area. 
Figure  6  illustrates  the  display  format  for  the  Symbol  Editor. 

Unlike  the  Layout  Editor,  whose  options  are  tnterchangable  sets  of 
cockpit  components,  the  Symbol  Editor  maintains  a  single  set  of  options. 
This  set  consists  of  six  graphic  primitives:  point,  line,  rectangle,  circle, 
polygon,  and  text.  All  cockpit  symbols  are  constructed  from  this  set. 
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Figure  8.  Typical  Symbol  Editor  Layout 


The  method  or  inserting  (placing)  objects  in  the  work  area  also  differs 
between  the  two  editors.  In  the  Layout  Editor,  object  placement  is 
determined  with  a  single  mouse  selection.  This  works  for  all  objects. 
Object  placement  in  the  Symbol  Editor  Is  a  bit  more  complicated.  Each 
graphic  primitive  (object),  because  of  Its  unique  geometric  form,  requires  a 
different  placement  method.  For  example,  points  are  positioned  in  the  work 
area  with  a  single  mouse  selection,  where  as,  lines,  rectangles,  circles,  and 
polygons,  require  multiple  insertion  points  to  be  defined.  The  methods  for 
inserting  these  primitives  will  be  presented  next. 

Defining  multiple  points  for  primitives  Is  accomplished  using  a 
rubberband*  technique.  Basically,  rubberbanding  Involves  defining  a  starting 
point  for  an  object,  followed  by  moving  the  cursor  to  define  other  points. 
As  the  cursor  is  moved,  the  object  is  streched  between  the  Initial  point  and 
the  cursors  current  position.  This  dynamically  alters  the  shape  of  the 
object  providing  the  user  with  Immediate  feedback  about  the  object's  shape. 
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Using  this  technique,  procedures  for  adding  lines,  rectangles,  circles,  and 
polygons  can  be  defined 

Lines,  rectangles,  and  circles  are  added  to  the  work  area  by  defining 
two  points  that  bind  the  primitive  to  the  work  area  In  the  case  of  the  line 
primitive,  the  first  point  defines  the  starting  point  while  the  second  point 
defines  the  end  of  the  line.  The  rectangle  primitive  uses  the  first  point  to 
defines  its  lower  left  hand  comer.  The  upper  right  hand  comer  is  then 
defined  by  the  second  point  The  circle  primitive  uses  the  first  point  to 
define  its  origin,  and  the  second  point  to  define  its  radius. 

Polygons  differ  from  the  other  primitives,  in  that  they  require  multiple 
points  to  define  their  shapes.  Polygons  are  drawn  by  specifying  a  series  of 
connected  line.  Each  line  forms  an  edge  to  the  polygon.  The  user  needs  only 
to  specify  the  starting  endpoint  once,  afterwards  the  endpoint  from  the 
previous  line  is  used  as  the  new  starting  endpoint.  Polygon  drawing  Is 
terminated  when  the  user  selects  a  point  outside  the  work  area  or  another 
option  is  selected. 

Text  is  the  only  primitive  that  requires  the  use  of  two  Input  devices, 
mouse  and  keyboard.  The  mouse  is  used  to  select  the  start  point  In  the  work 
area  where  the  text  is  to  be  inserted.  The  keyboard  is  then  used  to  enter  the 
actual  text  The  Insertion  point  must  be  selected  before  the  text  Is  entered, 
otherwise  the  interface  will  ignore  any  text  Input. 

The  Symbol  Editor  has  one  command  unique  to  its  processing  which  Is: 

Return  :  Transfers  control  back  to  the  Layout  Editor. 
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Two  graphic  editors,  the  Layout  Editor  and  the  Symbol  Editor,  are  used 
to  support  the  design  process.  The  Layout  Editor  supports  the  creation  and 
modification  of  cockpit  layout  displays,  where  as  the  Symbol  Editor 
supports  the  creation  and  modification  of  cockpit  symbology. 

Both  editors  have  in  common  several  functional  similarities;  such  as, 
graphical  interaction.  Iterative  development,  evolutionary  design,  and 
experimentation.  The  editors  differ  at  the  level  of  design  abstraction  at 
which  they  are  employed.  The  Layout  Editor  is  used  at  the  highest  level  of 
design  abstraction,  i.e.  cockpit  layout  editing.  The  Symbol  Editor  at  the 
lowest  level,  i.e.  cockpit  symbology  editing.  Together  they  provide  the 
design  tools  needed  to  construct  cockpit  layout  designs  In  a  dynamic, 
interactive  mode. 
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VI.  Librarian  D—Ign 


To  make  the  prototype  ALC  a  truly  functional  and  supportive 
environment  for  the  design  of  cockpit  layouts,  a  facility  for  storing  and 
retrieving  cockpit  layouts  and  cockpit  symbology  Is  needed.  Such  a  facility 
would  eliminate  the  practice  of  're-f wanting  the  wheel*  every  time  a  new 
design  Is  requested.  The  designer  would  have  available,  on-line,  a  means  of 
accessing  existing  cockpit  layouts  and  symbology  from  which  the  new 
design  could  take  root  The  prototype  ALC  supports  such  a  facility,  namely, 
the  Librarian  (Figure  9).  The  Librarian  Is  an  on-line,  archival  mechanism. 
Both  cockpit  layouts  and  cockpit  symbology  are  supported.  This  chapter 
describes  the  design  of  the  Librarian  In  terms  of  how  layouts  and  symbols 
are  stored,  how  they  are  retrieved,  and  problems  relating  to  consistency. 

Qbiflst.Stflragt 

All  objects  for  the  ALC  prototype  are  stored  In  libraries.  The  Librarian 
maintains  two  separate  libraries;  namely,  the  Layout  Library  and  the  Symbol 
Library.  As  the  names  Imply,  the  Layout  Library  Is  used  for  the  archival  of 
cockpit  layout  designs,  and  the  Symbol  Library  archives  all  the  cockpit 
symbols  used  In  the  system. 

Libraries  are  subdivided  into  classes.  Classes  are  logical  groupings  of 
objects.  Objects  are  assigned  classes  based  on  their  type.  Partitioning 
libraries  Into  classes  reduces  the  overall  complexity  of  the  library, 
allowing  for  efficient  and  rapid  access  of  Individual  objects. 
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liter  Interface 


Figure  9.  Librarian  Layer. 


The  Layout  Library  fa  partitioned  Into  claaaaa  baaed  on  cockpit  display 
types.  Figure  10  Illustrates  a  typical  Layout  Library  partitioned  into  three 
classes,  Aircraft,  HUD,  and  Threat  Each  class  in  a  Layout  Library  contains 
the  actual  cockpit  layout  displays  associated  with  a  particular  class  type. 
For  example,  the  class  HUD  contains  three  HUD  layouts. 

The  Symbol  Library  is  very  similar  In  structure  to  the  Layout  Library.  It 
too  is  partitioned  Into  classes,  but  the  partitioning  Is  based  on  symbol  type, 
not  layout  type.  Each  class  In  the  Symbol  Library  is  further  partitioned  into 
relations.  Relations  are  groupings  of  similar,  yet  different  cockpit 
components.  They  are  similar  in  that  they  are  classified  under  the  same 
class,  but  differ  In  content  A  relation's  content  Is  composed  of  individual 
symbols  defined  in  the  class's  symbol  families.  Symbol  families  are  the 
fundamental  symbol  groupings  in  the  library.  Each  family  contains 
permutations  of  a  single  symbol  type.  For  example,  the  family  Flight  Path 
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Figure  10.  Typical  Layout  Library. 


Marker  contains  different  representations  of  a  flight  path  marker.  The 
representations  differ,  but  they  symbolize  the  same  thing.  Figure  11 
Illustrates  a  typical  symbol  library. 

The  symbol  library  shown  In  Figure  1 1  is  partitioned  Into  three  classes; 
Aircraft,  HUD.  and  Threat  These  classes  should  not  be  confused  with  the 
classes  defined  in  Figure  10.  Although  they  have  the  same  names,  they  are 
not  the  same.  The  classes  In  Figure  10  represent  logical  groupings  of 
cockpit  layouts,  where  as,  the  classes  In  Figure  1 1  represent  the  logical 
groupings  of  cockpit  symbols  found  on  different  types  of  layout  displays. 
For  example,  the  symbol  class  HUD  contains  symbols  relating  to  the 
construction  of  HUD  type  displays.  It  would  not  contain  symbols  such  as 
aircraft  silhouettes  or  armaments.  These  symbols  would  most  likely  be 
contained  within  the  Aircraft  class. 
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Figure  1 1.  Typical  Symbol  Library. 


Each  class  In  the  Symbol  Library,  la  In  turn,  partitioned  Into  relations. 
The  class  HUD  contains  three  relations,  HR- 1,  HR-2,  and  HR-3.  Each  relation 
Is  composed  of  symbols  defined  In  the  HUD  class  symbol  families.  These 
families,  listed  left  to  right  in  Figure  II  are.  Flight  Path  Marker,  Pitch 
Ladder,  Missile  Aim,  and  Aircraft  Reference.  These  families  of  symbols 
define  all  the  HUD  symbols  currently  available  for  use  in  HUD  layout 
construction. 
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Cockpit  layouts  and  symbology  are  retrieved  from  the  libraries  by  the 
Layout  Editor  and  the  Symbol  Edltori  repectlvely.  The  Layout  Editor  allows 
the  user  to  access  both  layout  designs  and  symbol  relations.  Symbol 
relations  are  mapped  directly  onto  the  Layout  Editors  display  as  option 
windows.  The  Layout  Editor  has  the  capability  of  modifying  the  layout 
design  only.  It  cannot  directly  modify  the  contents  of  the  option  window 
(i.e.  symbol  relation).  Additions  or  modifications  to  a  symbol  In  the  option 
window  can  only  be  performed  via  the  Symbol  Editor. 

The  Symbol  Editor  can  directly  access  symbol  relations  or  families. 
All  modifications  to  relations  are  based  on  the  content  of  the  individual 
families.  In  order  to  add  a  symbol  to  a  relation  that  symbol  must  first  be 
defined  within  a  family.  Modifications  to  symbols  are  also  performed  at  the 
family  level.  Deletions  are  possible  at  both  levels.  Deleting  a  symbol  from 
a  relation  simply  removes  it  from  that  relation.  Deleting  a  symbol  from  a 
family  removes  the  symbol  from  the  system. 

Camlatiigy 

Besides  being  able  to  store  and  retrieve  cockpit  layouts  ana  symbology, 
the  Librarian  Is  also  tasked  with  the  responsibility  of  maintaining 
consistency  between  the  two  libraries.  Inconsistencies  between  the  two 
libraries  has  the  possibility  of  developing  when  ever  a  cockpit  symbol  Is 
modified  or  deleted.  For  example,  if  a  symbol  Is  deleted  from  a  symbol 
family.  Its  removal  has  the  possibility  of  effecting  all  relations  that  use 
the  symbol  and  all  cockpit  layouts  that  use  the  relation.  The  effect  of 
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removing  a  single  symbol  results  in  a  propagation  of  changes  throughout  the 
entire  system.  If  the  Librarian  does  not  support  active  consistency 
checking,  the  Integrity  of  the  both  libraries  cannot  be  guaranteed 

i 

Summary 

The  Librarian  is  an  on-line,  archival  mechanism  that  supports  the 
storage  and  retrieval  of  cockpit  layout  designs  and  cockpit  symbology. 
Layouts  and  symbology  are  stored  In  separate  libraries.  These  libraries  are 
parti  toned,  based  on  layout  and  symbol  type  Into  logical  groupings  called 
classes.  Each  class  within  a  library  contains  the  actual  cockpit  object  (l.t 
layout  or  symbol). 

All  classes  are  accessed  via  one  of  the  two  editors  supported  by  the 
ALC  prototype.  The  Layout  Editor  allows  direct  access  to  cockpit  layouts 
and  Indirect  access  to  symbol  relations  (option  window).  The  Symbol  Editor 
provides  a  means  of  adding,  deleting,  and  modifying  cockpit  symbology. 
Changes  to  cockpit  symbols  has  the  potential  of  creating  Inconsistencies 
between  the  two  libraries.  It  thus  becomes  critical  that  some  type  of 
active  consistency  checking  is  performed  by  the  Librarian  to  ensure  layout 
and  symbol  Integrity. 
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Ylt.  impltmtnutlgn 


Implementation  la  the  process  of  mapping  an  abstract  representation  of 
a  problem  (l.e.  design)  Into  a  concrete,  functional  model.  Three  areas  of  the 
ALC  prototype  design  were  Implemented  In  this  thesis,  namely;  hardware, 
environmental,  and  the  application  itself.  Hardware  implementation  deals 
with  defining  the  actual  graphics  system  on  which  the  ALC  prototype  is 
hosted.  Environmental  Implementation  deals  with  the  programming 
environment  In  which  the  ALC  prototype  is  to  function.  For  this  thesis  effort 
an  object-oriented  environment  was  chosen,  Finally,  application 
implementation  Is  the  actual  implementation  of  the  ALC  prototype  itself. 
Each  Implementation  phase  will  be  discussed  In  detail  In  the  following 
sections. 

Hardware 

The  ALC  prototype  is  implemented  on  a  Raster  Technologies  Model 
One/25  graphics  system.  This  system  was  chosen  for  Its  high  resolution 
display,  Interactive  capabilities,  and  full  availability  for  this  thesis  effort. 
The  description  of  this  system  13  divided  Into  five  areas,  display 
technology,  Input  devices,  output  devices,  storage  and  processing,  and 
software  drivers.  The  first  four  areas  correspond  to  the  hardware 
requirements  quidelines  provided  in  Chapter  2.  The  actual  components  that 
comprise  these  areas  are  illustrated  in  Figure  12.  A  description  of  the 
software  drivers  needed  to  make  all  the  hardware  components  work  is  also 
provided. 
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Figure  12.  ALC  Prototype  Hardware  Configuration. 


Display  Technology.  The  Raster  Technologies  Model  One/25 
employs  the  use  of  a  high  resolution  raster  display.  The  Model  One/25 
supports  two  levels  of  resolution,  512  x  512  and  1024  X  1024  pixels.  In 
addition,  the  Model  One/25  Is  capable  of  displaying  over  16  million  colors  In 
the  512  x  512  mode.  The  high  resolution  and  color  capabilities  of  this 
display  make  it  an  excellent  choice  for  hosting  the  ALC  prototype. 

Input  Devices.  The  Model  One/25  currently  supports  two  Input 
devices,  an  alphanumeric  terminal  and  a  graphics  tablet  with  a  mouse.  The 
alphanumeric  terminal  Is  not  used  as  an  Input  device.  It  is  used  primarily  to 
issue  system  commands  to  the  Model  One/25  and  to  perform  system 
Initialization  (See  Appendix  A).  Inputs  from  the  alphanumeric  terminal  are 
ignored  by  the  ALC  prototype  software. 
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The  graphics  tablet  with  mouse  was  used  exclusively  as  an  input  device 
for  the  ALC  prototype.  Ail  user  actions  (such  as  cursor  movement  and 
selection)  are  conveyed  to  the  software  through  the  mouse.  The  particular 
mouse  used  supports  16  different  function  buttons.  All  but  one  button 
(button  0)  Is  used  as  simple  pick  devices.  Button  0  is  dedicated  to  providing 
the  cursor  with  the  current  mouse  position  (this  is  a  hardware  quirk  of  the 
Model  One/25).  Selecting  this  button  has  no  effect  on  processing.  The  other 
buttons  when  pushed,  function  as  simple  pick  devices,  causing  a  selection 
event  to  be  registered  in  the  system  event  queue.  This  allows  the 
application  software  to  query  the  event  queue  and  process  any  pending 
events. 

Output  Devices.  The  Model  One/25  currently  does  not  support  output 
devices  other  than  the  display  screen. 

Processing  and  Storage.  The  processing  capabilities  of  the  system 
are  divided  between  two  systems,  an  Independent  host  computer  and  the 
Model  One/25  display  processor.  All  application  software  is  developed, 
stored,  and  executed  on  the  host  computer,  while  all  graphic  operations  are 
performed  on  the  Mode)  One/25.  The  host  computer  performs  the  actual 
computational  tasks  required  of  the  application,  passing  off  the  graphic  and 
Interactive  tasks  to  the  Model  One/25.  The  Model  One/25  serves  as  an 
intelligent  graphics  terminal,  interpreting  and  performing  graphic 
commands  sent  to  it  by  the  host  computer. 

The  host  computer  was  a  VAX  1 1  /785,  operating  under  BSD  UNIX  version 
4.2.  Communication  between  the  VAX  and  the  Model  One/25  was  conducted 
over  a  9600  baud  channel,  routed  through  a  local  area  network.  The  channel 
bandwidth  seemed  sufficient  when  the  VAX  was  not  heavily  used.  However, 
Interactive  response  times  were  degraded  as  VAX  usage  increased. 
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Owlet  Drivers,  a  problem  often  associated  with  hardware 
configurations  as  described  above,  is  the  lade  of  reliable  device  drivers  to 
communicate  with  the  graphics  hardware.  This  thesis  was  not  without  such 
a  problem.  Device  drivers  are  the  actual  software  modules  that  allow  a  host 
system  to  Interact  directly  with  a  piece  of  graphic  hardware.  They  function 
as  Interpreters  by  translating  host  commands  into  commands 
understandable  by  the  graphics  hardware.  The  device  drivers  Implemented 
In  this  thesis,  translate  graphic  commands  issued  by  the  application 
software  into  ASCII  character  strings  representing  the  hexldecimal  value  of 
a  Model  One/25  operator.  This  string  was  then  sent  over  the  network  to  the 
Model  One/25  where  it  was  interpreted  and  the  appropriate  task  performed. 
Appendix  F  provides  a  detailed  description  of  the  device  drivers  that  were 
Implemented. 

Objfct-Qrientsii.ayattin 

This  section  describes  the  graphical  object-oriented  environment  that 
was  developed  and  Implemented  as  part  of  this  thesis  effort  to  support  the 
implementation  of  the  ALC  prototype.  This  environment  was  based  on 
object-oriented  concepts  derived  from  such  systems  as  Smalltalk  [Goldberg 
and  Robson,  19831,  Traits  [Curry  and  Ayers,  19841,  Object  Oriented 
Pre-Compiler  (OOPC)  [Cox,  1 983],  and  IconMaker  [Kramer,  1 9841  The  intent  of 
this  environment  was  not  to  develop  a  'production  quality'  product,  but 
rather  a  test-bed  In  which  object-oriented  concepts  could  be  applied  to  the 
ALC  prototype  effort.  With  this  in  mind,  this  section  wilt  proceed  In  the 
following  direction,  first  object-oriented  concepts  will  be  discussed  In 
general  terms  to  familiarize  the  reader.  Next,  the  applicability  of 
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object-oriented  concepts  to  graphic  systems  will  be  presented,  followed  by 
a  description  of  the  actual  environment  that  was  Implemented. 

Object-Oriented  Concents.  The  distinction  between  traditional 
programming  environments  and  object-oriented  environments  deals  with  the 
way  the  environment's  computational  model  Is  defined.  A  computational 
model  describes  how  the  various  entitles  In  an  environment  interact  to 
perform  a  computational  task.  In  both  environments  the  tasks  or  goals  are 
identical;  the  difference  lies  In  the  definition  of  the  entitles  that  inhabit 
the  environment  and  their  method  of  Interaction. 

Traditional  programming  environments  are  based  on  an 
operator/operand  model  lCox.52: 19841  This  model  views  the  computational 
process  as  being  operations  performed  on  operands.  The  environment  is 
divided  Into  two  distinct  sets  of  entitles,  operators  (procedures)  and 
operands  (data).  Operators  are  a  isldered  active  entities  In  the  environment 
that  manipulate  the  passive  data  Items  passed  to  them.  Operands  are 
passive  in  nature,  and  are  only  changed  by  an  operator. 

Interaction  between  these  entitles  is  usually  supported  by  some  type  of 
direct  invocation  mechanism  (1.e.  subroutine  or  procedure  call).  Operators 
are  directly  Invoked  to  manipulate  a  set  of  operands.  The  invocation  process 
In  effect  establishes  'how'  something  should  be  done.  This  usually  places 
restrictions  on  the  type  of  operand  that  an  operator  can  manipulate.  This,  In 
turn,  can  populate  the  environment  with  sets  of  operators  that  conceptually 
perform  the  same  operation  on  different  data  types. 

An  alternative  to  the  operator/operand  model  Is  the  message/operand 
model.  This  model  forms  the  basis  for  object-oriented  environments. 
Unlike  the  operator/operand  model,  where  data  and  procedures  are  viewed  as 
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separate  entitles,  the  message/operand  model  merges  the  two  into  a  single 
entity  referred  to  as  an  object.  The  object  serves  as  the  focal  point  for  all 
computations.  Since  objects  combine  the  properties  of  operands  and 
operators,  they  are  capable  of  being  manipulated  as  well  as  being  the 
manipulator  [Robson,  1 98 1 :76i 

Objects  interact  via  a  message  passing  paradigm.  A  message  is  a 
request  from  one  object  to  another  to  perform  one  of  its  operations.  The 
key  word  in  this  description  is  'request1.  The  receiver  of  the  message 
determines  'how'  it  will  handle  the  message,  not  the  sender.  The  sender  can 
only  request  ’what'  should  be  dou,  it  has  no  control  over  'how'.  Invocation 
is  performed  indirectly  as  opposed  to  more  traditional  direct  Invocation 
methods.  Message  passing  has  a  direct  impact  on  the  number  of  operators 
needed  to  perform  similar  tasks.  Instead  of  using  a  set  of  different 
messages  (l.e.  operators)  to  Invoke  a  similar  operation  In  a  set  of  different 
objects  (l.e.  operands),  message  passing  permits  identical  messages  can  be 
sent  to  all  objects  Invoking  a  behavior  unique  to  that  object  The 
environment  becomes  more  compact  and  consistent,  since  a  single  method  Is 
used  to  invoke  computations  Instead  of  a  set  of  methods. 

The  reader  should  refer  to  Appendix  B  for  a  detailed  discussion  of 
terminology  and  characteristics  associated  with  object-oriented  systems. 

Graphic  Systems.  The  use  of  object-oriented  concepts  Is  not  new  to 
graphic  systems.  Perhaps  the  earliest  system  to  employ  a  subset  of  these 
Ideas  was  Sketchpad  [Sutherland,  1 9801  Sketchpad  was  one  of  the  first 
systems  to  provide  true  Interactive  capabilities.  Its  similarity  to 
object-oriented  systems  of  today  is  found  in  Sketchpad's  definition  and 
creation  of  graphics  entities  (objects). 
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Sketchpad  presented  two  views  of  objects,  the  first,  and  most 
Intuitive,  was  that  of  a  graphic  entity.  This  entity  took  form  on  the  display 
screen  and  was  capable  of  being  manipulated  via  Interactive  means. 
Sketchpad  supported  basic  geometric  objects  such  as  lines,  circles,  and 
points. 

The  second  view  was  actually  an  implementation  abstraction  of  the 
first  At  the  Implementation  level,  objects  were  quantified  as  being  sets  of 
variables  and  constraints.  Variables  defined  the  objects  form,  while  the 
constraints  modified  the  form  to  satisfy  a  given  design  or  geometric 
requirement.  The  association  of  data  and  methods  (constraints)  for 
modifying  that  data  Is  very  similar  to  concepts  found  in  most 
object-oriented  systems  today. 

Besides  a  similar  object  definition,  Sketchpad  also  employed  an 
‘instantiation'  technique  to  create  objects.  Objects  were  Instances  of  a 
'master  picture'.  A  master  picture  was  an  original  description  of  a  specific 
object.  Objects  were  instantiated  by  duplicating  the  master  picture,  then 
modlflng  the  variables  to  describe  the  new  object  (Instance).  This  Is  very 
similar  to  the  class  concept. 

Sketchpad  greatly  influenced  the  interactive  nature  of  graphic  systems. 
However,  the  object-oriented  concepts  ft  fostered  did  not  gain  wide 
acceptance.  This  may  have  been  due  the  Interactive  capabilities 
overshadowing  these  Ideas,  or  perhaps  the  object-oriented  model  itself 
was  not  complete  enough  IRentsch,  1 982:551.  In  either  case,  the 
object-oriented  concepts  that  did  survive  were  confined  to  the  portrayal 
of  graphic  Images  on  the  screen,  defining  graphic  Images  in  terms  of 
variables,  and  duplicating  images  via  instantiation. 
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The  majority  of  the  graphic  systems  In  use  today  (GKS,  CORE,  PHI6S, 
etc)  have  been  Implemented  within  traditional  programming  enviroments. 
FORTRAN,  because  of  its  early  use,  seems  prevalent  as  the  implementation 
choice,  however  'C'  [Denny,  1 086]  and  Ada  (Hanson,  1 986]  bindings  have  also 
become  available.  These  systems  embrace  only  the  object-oriented 
concepts  promoted  by  Sketchpad  and  little  more.  The  idea  of  combining  data 
with  procedures  is  still  not  Implemented. 

It  hasn't  been  since  the  development  of  true  object-oriented  systems, 
such  as  Smalltalk,  that  graphic  systems  have  finally  embraced  the  concepts 
associated  with  object-oriented  systems.  Several  object-oriented 
graphical  implementations  are  described  in  current  literature  [Goldberg  and 
Rcbson,1983],  [W1ssk1rchen,1986],  (Lubinskl  and  Hutzel,1984],  ax) 
(Reiss,  19861 

Support  Environment  The  graphical  object-oriented  environment 
implemented  as  part  of  this  thesis,  provides  a  flexible,  yet  consistent 
framework  for  defining  a  wide  range  of  graphic  metaphors.  This  section 
describes  these  metaphors  without  providing  the  detailed  Implementation 
concerns.  The  reader  should  refer  to  Appendix  C  for  implementation  details. 

Currently  three  views  of  graphics  programming  are  supported.  They  are 
primitive,  user  interface,  and  application  views.  The  primitive  view 
provides  the  foundation  of  the  system.  It  supports  the  essential,  inseparable 
graphic  constructs  tt»at  allows  other  views  to  be  built.  The  user  interface 
provides  f*e  interactive  mechanism  for  the  environment.  It  is  through  this 
level  that  the  user  can  directly  manipulate  the  system.  The  application 
view  ties  together  both  the  primitive  and  user  interface  views  to  satisfy  a 
users  requirement  It  is  the  most  dynamic  portion  of  the  environment. 
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allowing  multiple  applications  to  be  constructed  from  primitive  and  user 
interface  components. 

Each  view  provides  a  different  level  of  development  abstraction,  yet 
they  are  handled  by  environment  in  the  same,  consistent  manner.  The  user  is 
never  forced  to  jump  abstraction  levels  when  developing  software.  This 
allows  the  user  to  mix  abstraction  levels  freely  without  being  burdened 
with  the  implementation  details.  A  consistent  abstraction  is  maintained  by 
making  all  components  in  the  environment  objects.  All  components  of  the 
environment  are  accessed  via  a  consistent  message  passing  schema, 
regardless  of  the  abstraction  level  they  represent 

Primitive  View.  Primitives  form  the  basic  foundation  of  all  graphic 
environments.  They  are  the  simplest  objects  in  the  environment  serving  as 
building  blocks  for  more  complex  objects. 

Currently  six  classes  of  primitives  are  supported;  namely.  Circle,  Line, 
Point,  Polygon,  Rectangle,  and  Text  Each  class  defines  a  unique  geometric 
figure  and  methods  that  are  unique  to  its  form.  All  graphic  Images 
displayed  on  the  screen  are  combinations  of  one  or  more  of  these  objects. 

All  primitive  classes  Inherit  their  attributes  from  a  Graphics  Primitive 
class.  This  class  gives  each  primitive,  characteristics  common  to  all 
graphic  objects.  Specifically,  the  Graphics  Primitive  class  provides  the 
following  attributes: 

cx,cy:  Center  location  of  the  object. 

colon  Defines  the  objects  color. 

solid  fill:  indicates  if  the  object  is  solid  or  not. 

draw  mode:  Indicates  how  the  object  is  drawn  on  the  screen. 

area:  The  objects  area  on  the  screen  (In  pixel  units). 

extent:  Defines  the  objects  rectangular  extent. 
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In  addition  to  the  classes  defined  above,  a  composite  class  is  also 
supported  The  class,  Composite,  provides  instances  that  are  composed  of 
instances  of  other  primitive  classed  In  other  words,  the  Composite  class 
provides  the  capability  of  constructing  complex  graphic  images  from  simple 
graphic  primitives,  yet  the  resulting  graphic  image  is  treated  as  a  single 
entity.  For  example,  one  could  Instantiate  an  object  call  Aircraft.  Aircraft 
would  refer  to  a  single  entity,  but  in  actuality  Aircraft  Is  a  composite  of 
more  general  parts  (i.e.  objects)  such  as  Fuselage,  Wing,  Tail,  etc.  Together 
all  the  parts  define  an  aircraft 

Composite  objects  may  also  contain  other  composite  objects.  For 
example,  the  object  ‘Wing*  could  actually  be  a  composite  object  consisting 
of  more  simpler  objects  such  as  Aileron  and  Flap.  Together  these  simple 
objects  define  Wing,  which  in  turn  is  used  in  the  definition  of  Aircraft.  This 
nesting  of  composite  objects  Is  very  similar  to  graphic  structures 
Implemented  in  graphic  modeling  environments  such  as  PHI6S  [Abi-Ezzi  and 
Bunshaft,  19861  The  reader  should  refer  to  Appendix  D  for  a  detailed 
description  of  the  composite  and  graphic  primitive  classes. 

User  Interface.  Currently,  there  are  seven  user  interface  classes 
supported  by  the  environment.  These  classes  are  Command,  Cursor,  Dialogue 
Window,  Display  Window,  Option  Window,  and  Pop-Up  Menu.  Each  class 
provides  a  unique  way  of  allowing  the  user  to  Interface  to  the  envlronement. 
A  functional  description  of  each  class  follows. 

Command:  Supports  the  display  and  selection  of  commands 

via  a  command  button. 

Cursor.  Handles  the  form  and  visibility  of  the  cursor. 

Dialogue  Window:  Provides  a  consistent  means  of  querying  the  user. 
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Display  Window:  Provides  an  Interactive  medtisn  for  display  and 
manipulation  of  primitve  and  composite  objects. 

Mouse:  Handles  all  mouse  functions,  such  as,  tracking  and 

event  queuing. 

Option  Window:  Provides  a  standard  way  of  presenting  objects 
for  selection. 

Pop-Up  Menu:  Dyanmlc  medium  for  command  selection. 

A  detailed  description  of  each  user  interface  class  Is  provided  in 
Appendix  D. 

Application.  The  final  area  supported  by  the  environment  Is  the 
application.  An  application  Is  the  actual  task  or  requirement  that  the  ueer 
Is  attempting  to  satisfy.  Applications  are  supported  by  assembling  together 
various  components  from  the  primitive  and  user  Interface  classes.  These 
classes  should  support  all  the  components  needed  to  build  an  application.  If 
they  don't,  a  new  class  should  be  constructed,  rather  then  implementing  the 
capability  within  the  application  Itself.  This  will  not  only  expand  the 
number  of  classes  available  for  application  development,  but  will  also 
provide  consistency  within  the  environment  Software  development 
becomes  the  process  of  creating  classes  instead  of  programs. 

Applications  are  viewed  as  master  objects  controlling  the  interaction 
or  subordinate  objects.  They  do  not  Impart  any  new  capabilities  to  the 
environment,  rather  they  simply  rearrange  existing  capabilities  (classes)  to 
perform  new  tasks.  This  is  similar  to  a  'tinker-toy*  set.  The  components  of 
the  set  constitute  the  environment;  how  they  are  put  together  determines 
the  application.  This  same  metaphor  can  also  be  applied  to  the  cockpit 
design  process. 
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The  environment  was  originally  intended  to  support  three  applications, 
Layout  Editor,  Symbol  Editor,  and  the  Librarian.  But  because  of  its  generic 
nature,  it  should  be  possible  to  support  a  multitude  of  different 
applications. 

Ann  licet  Inn 

The  ALC  prototype  consists  of  four  separate  but  interrelated 
components,  namely;  the  user  interface.  Layout  Editor,  Symbol  Editor,  and 
the  Librarian,  implementation  of  ail  four  components  was  beyond  the  scope 
of  this  thesis  effort  As  such,  a  concerted  effort  was  made  to  demonstrate 
the  feasibility  of  the  ALC  concept  by  Implementing  the  user  Interface  and 
Layout  Editor. 

It  was  felt  that  the  exclusion  of  the  Symbol  Editor  and  the  Librarian 
would  not  significantly  impact  the  primary  goal  of  the  ALC  prototype,  which 
was  to  demonstrate  the  feasibility  of  interactive  cockpit  display 
generation.  Those  capabilities  supported  by  the  Symbol  Editor  and  Librarian 
(l.e.  symbol  construction  and  archival)  could  be  Initially  emulated  within  the 
Layout  Editor,  with  the  understanding  that  a  complete  implementation  of  the 
ALC  prototype  would  entail  a  detailed  Implementation  of  the  Symbol  Editor 
and  Librarian.  With  this  in  mind,  the  remainder  of  this  chapter  will  focus  on 
presenting  the  Implementation  of  the  user  Interface  and  the  Layout  Editor. 

User  Interface.  The  user  Interface  was  Implemented  more  as  a  part 
of  the  support  environment  than  as  a  part  of  the  ALC  prototype  Itself.  The 
functions  and  capabilities  of  the  user  interface  tend  to  be  more  generic  In 
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nature  than  application  specific.  The  user  Interface  is  more  of  a  ’kernel* 
than  a  standalone  application. 

Layout  Editor.  The  purpose  of  the  Layout  Editor  is  to  support  the 
creation  and  subsequent  modification  of  cockpit  layout  designs.  The  Layout 
Editor  currently  supports  three  cockpit  layout  types,  aircraft  ordnance 
loading,  basic  HUD  design,  and  threat  situation  displays.  These  types  were 
chosen  because  they  represent  a  diverse  range  of  possible  applications  to  be 
supported  by  the  ALC.  The  Layout  Editor  is  currently  limited  to  three  layout 
types  due  to  the  lack  of  librarian  support  Because  the  Librarian  Is  not 
Implemented,  ft  became  necessary  for  the  Layout  Editor  to  emulate  a 
primitive  librarian  system  The  primitive  library  is  Intended  only  for 
demonstration  purposes,  it  is  not  intended  to  be  a  fully  functional  library. 
When  the  Librarian  is  finally  implemented  and  integrated  with  the  Layout 
Editor,  the  Layout  Editor  should  be  able  to  support  an  unlimited  number  of 
cockpit  layout  types. 

Besides  supporting  only  a  limited  number  of  layout  types,  the  number  of 
symbols  defined  for  each  type  is  also  limited.  Each  symbol  associated  with 
a  type  must  be  hardcoded  to  that  type.  If  the  user  wishes  to  add,  delete,  or 
modify  a  symbol,  an  off-line  change  to  the  software  definition  of  the 
symbol  is  required.  Again,  this  is  directly  related  to  the  lack  of  a  symbol 
editor.  Once  a  symbol  editor  is  Implemented,  it  should  be  possible  to  modify 
a  cockpit  symbol  while  on-line,  for  any  of  the  layout  types  in  the  library. 

Although  the  Layout  Editor  suffers  from  the  direct  lack  of  support  of 
the  Symbol  Editor  and  Librarian,  the  minimal  capabilities  these  components 
provide,  are  emulated  within  the  Layout  Editor.  The  Layout  Editor  presents  a 
complete  picture,  in  and  of  itself,  even  without  the  implementation  of  the 
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Figure  1 3.  Example  or  an  Aircraft  Ordnance  Loading  Layout 


Symbol  Editor  and  Librarian.  The  Layout  Editor  Is  best  illustrated  by 
examples  of  the  actual  layout  types  suppported. 

Aircraft  Ordnance  Loading.  The  first  layout  type  supported  by  the 
Layout  Editor  provides  the  designer  with  the  capability  of  configuring 
different  types  of  aircraft  with  different  types  of  ordnance.  Currently  two 
types  of  symbol  classes  compose  this  layout  type;  namely,  aircraft 
silhouettes  and  missiles.  The  aircraft  silhouette  class  currently  contains 
the  figures  of  three  aircraft;  F-4,  F- 1 5,  and  the  F-16.  The  missile  class  is 
composed  of  four  different  types;  Harm,  Maverick,  Sidewinder,  and  Sparrow. 

With  these  two  symbol  classes,  the  designer  can  construct  aircraft 
loading  displays  similar  to  Figure  13.  Figure  13  Illustrates  an  F-15 
configured  with  four  sparrow  and  one  Maverick  missile. 
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1  Info  1 1  setup  I  I  file  1 1  edit  1 1  quit  | 

Figure  14  Example  of  a  Simple  HUD  Layout 

HUD  Design.  The  Layout  Editor  currently  supports  a  primitive  HUD 
design  capability.  Only  a  single  symbol  class  is  provided  for  component 
selection  This  class  contains  the  following  symbols;  flight  path  marker, 
angle  of  attack  error  Indicator  (aoa).  aircraft  reference  symbol.  Inertial 
landing  system  (11s)  bars,  mtsslle  aiming  rectlle.  and  pitch  ladder.  Figure 
14  shows  a  possible  HUD  created  from  this  class.  The  HUD  in  Figure  14 
contains  a  flight  path  marker,  aoa  error  indicator,  aircraft  reference 
symbol,  and  pitch  ladder.  When  the  Symbol  Editor  and  Librarian  are 
Implemented,  It  should  be  possible  to  have  Individual  symbol  classes  for 
each  of  the  symbols  shown  In  the  current  class.  This  would  provide  the 
designer  with  an  interactive  means  of  experimenting  with  different  HUD 
representations. 
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Figure  15.  Example  or  a  Threat  Situation  Layout 

Threat  Situation.  The  last  type  of  layout  supported  by  the  Layout 
Editor  Is  the  threat  situation  layout  Threat  situation  provides  the  pilot 
with  a  ’birds  eye*  view  of  the  ground  threats  for  a  particular  region.  From 
such  a  display  the  pilot  can  quickly  identify  potential  hazards  and  plan 
evasive  actions. 

The  threat  situation  layout  supports  three  symbol  classes;  terrain, 
surface  to  air  missiles  (SAM),  and  anti-aircraft  (AA).  The  terrain  class 
provides  a  single  map  for  selection.  The  SAM  class  represents  threats  as 
circles.  The  size  of  the  circle  displayed  depends  upon  the  threat  range  of 
the  SAM  selected.  Inscribed  within  each  threat  circle  is  a  number  indicating 
the  SAM  type.  The  same  representation  holds  for  AA,  except  AA  threats  are 
represented  as  octagons. 

Figure  15.  Illustrates  an  example  of  a  threat  situation  display.  This 
display  contains  two  SAM  sites  and  one  AA  site. 
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It  should  bt  reemphasized  that  the  current  limitation  of  three  layout 
types  Is  solely  a  result  of  not  Implementing  the  Symbol  Editor  and  Librarian. 
More  layout  types  could  have  been  added  to  the  Layout  Editor,  but  Is  was  felt 
that  the  current  layout  types  justly  demonstrate  the  Layout  Editors 
capabilities. 


This  chapter  has  presented  the  Implementation  of  the  ALC  prototype. 
The  prototype  was  Implemented  In  three  phases;  hardware,  support 
environment,  and  the  actual  appl  (cation. 

Hardware  Implementation  dealt  with  defining  the  hardware 
environment  that  the  ALC  prototype  was  hosted  on.  It  Is  currently  supported 
by  a  Raster  Technologies  Model  One/25  graphics  processor. 

A  graphical  object-oriented  environment  was  Implemented  as  a  part  of 
this  thesis  to  provide  a  flexible  foundation  for  the  actual  Implementation. 
Object-oriented  concepts,  derived  primarily  from  Smalltalk,  shaped  that 
implementation. 

Implementation  of  the  ALC  prototype  was  originally  targeted  to  Include 
the  user  interface.  Layout  Editor,  Symbol  Editor,  and  the  Librarian.  Such  and 
effort  was  soon  discovered  to  be  beyond  the  scope  of  a  single  thesis. 
Because  of  this,  a  functional  subset  of  the  ALC  prototype  was  chosen  for 
implementation.  This  subset,  consisting  of  the  user  Interface  and  Layout 
Editor,  encompasses  the  essence  of  the  ALC  prototype  effort  by  providing 
the  capability  for  constructing  cockpit  layout  designs.  The  Layout  Editor 
currently  supports  three  type  of  layouts;  aircraft  ordnance  loading,  simple 
HUD,  and  threat  situation.  Examples  of  these  layouts  were  given.  The 
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Layout  Editor  Is  capable  of  supporting  otter  layouts!  but  ft  was  felt  that 
those  selected  layout  types  were  diverse  enough  to  demonstrate  the  generic 
editing  capabilities  of  the  Layout  Editor  without  adding  additional  layout 
types. 
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ML  Conclusions  md  Bgcounmubtetlons 


Cancmaiana 

This  thesis  has  been  a  preliminary  attempt  to  define  (quantify)  a 
possible  ALC  representation  for  the  AC/CSRL.  it  has  focused  on  the  rapid 
prototyping  of  pictorial  type  cockpit  displays  via  the  use  of  existing  cockpit 
layouts  and  symbology.  This  research  has  resulted  in  the  design  and 
implementation  of  a  highly  Interactive,  graphics  based  environment  known 
as  the  ALC  prototype. 

The  ALC  prototype  was  designed  to  support  four  major  AC/CSRL  ALC 
requirements;  namely, 

1.  user  supportiveness, 

2.  interactive  creation  and  modification  of  cockpit  layouts, 

3.  interactive  creation  and  modification  of  cockpit  symbology,  and 

4.  storage  and  retrieval  of  cockpit  layouts  and  symbology. 

Due  to  limited  time  and  resources,  the  current  ALC  prototype 
implementation  only  supports  the  first  two  requirements;  user 
supportiveness  and  cockpit  layout  generation.  However,  this 

implementation  has  shown  to  be  sufficient  to  demonstrate  the  centra) 
theme  of  the  AC/CSRL  ALC  concept;  namely,  the  Interactive  support  of 
cockpit  display  generation.  Implementation  of  the  remaining  requirements 
would  greatly  enhance  the  capabilities  of  the  ALC  prototype  and  would 
provide  a  suitable  framework  for  demonstrating  a  broad  range  of  design  and 
implementation  Issues  associated  the  AC/CSRL  ALC  effort. 
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This  thesis  has  demonstrated  the  concepts  proposed  by  the  AC/C5RL 
effort  are  feasible  and  can  be  implemented  using  todays  technology.  What 
this  thesis  did  not  demonstrate,  nor  did  it  attempt  to,  was  what  the  final 
ALC  representation  should  be.  Rather,  this  thesis  proposed  a  candidate  ALC 
representation  based  on  several  Key  ALC  requirements. 

Aside  from  demonstrating  the  ALC  concept  from  the  user's  viewpoint, 
this  thesis  also  addressed  the  use  of  object-oriented  concepts  in  the  design 
and  implementation  of  the  ALC  prototype  software.  A  consistent 
object-oriented  metaphor  was  applied  to  all  levels  of  the  ALC  effort  At  the 
user  level,  all  interactions  were  viewed  as  the  manipulation  of  cockpit 
'objects'.  The  software  design  was  based  on  an  object-oriented  design 
methodology,  and  the  actual  software  itself  was  implemented  in  an 
object-oriented  fashion.  This  approach  provided  a  consistent  framework 
from  the  application  down  to  the  Implementation;  this  Is  seldom  attainable 
with  more  traditional  approaches. 

In  addition  to  providing  a  consistent  metaphor,  an  object-oriented 
implementation  supporting  multiple  inheritance,  proved  a  viable  means  of 
rapidly  generating  software.  Classes,  once  fully  implemented  and  tested, 
served  as  the  foundation  for  building  other  classes.  Building  new  classes 
upon  the  functional  capabilities  of  existing  classes  reduced  the  need  for 
extensive  software  development  and  testing. 

Although  this  thesis  addressed  a  specific  application,  the  rapid 
prototyping  of  pictorial  cockpit  displays,  the  graphics  environment  that 
supports  the  prototype  ALC  was  developed  as  generic  as  possible.  It  should 
be  possible  to  extend  the  Ideas  and  concepts  embodied  in  this  environment 
to  other  areas  requiring  the  rapid  prototyping  of  pictorial  displays. 
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Recommendations  are  divided  into  two  areas;  short  term  and  long  term. 
Short  term  recommendations  suggest  ways  for  immediately  enhancing  the 
capability  of  the  ALC  prototype.  Long  term  recommendations  are 
enhancements  or  issues  identified  as  part  of  this  thesis  effort  that  could 
impact  directly  the  AC/CSRL  development  effort 

Short  Term.  The  most  Immediate  short  term  enhancement  that  could 
be  applied  to  the  existing  ALC  prototype  implementation  would  be  the 
Implementation  and  integration  of  the  Symbol  Editor  and  Librarian  with  the 
Layout  Editor.  Currently,  the  Layout  Editor  must  emulate  specific 
capabilities  originally  intended  to  be  supported  by  the  Symbol  Editor  and 
Librarian  (i.e.  cockpit  symbol  construction  and  layout  retrieval).  The 
emulation  Is  primitive  and  detracts  from  the  original  Intention  of  the 
Layout  Editor,  namely;  cockpit  layout  construction.  By  Implementing  the 
Symbol  Editor  and  Librarian,  the  ALC  prototype  would  truly  be  a  supportive 
environment. 

The  ALC  prototype  could  also  be  enhanced  by  rehosting  the  software  on 
a  dedicated  graphics  workstation.  Currently,  the  ALC  prototype  software  is 
hosted  on  a  Raster  Technologies  Model  One/25  graphics  processor  connected 
to  a  time-shared  VAX  11/785.  In  this  configuration,  the  Model  One/25 
serves  as  an  intelligent  graphics  terminal,  while  the  VAX  11/785  performs 
the  majority  of  the  computational  tasks.  User  interaction  is  often  hampered 
by  this  set  up.  Besides  being  constrained  by  a  relatively  slow  (9600  baud) 
communication  channel,  the  VAX  Is  sometimes  heavily  utilized  by  other 
applications  resulting  In  intermittent  bursts  of  high  user  response  followed 
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by  no  response  at  all.  This  hit  and  miss  response  mode  significantly 
detracts  from  the  interactive  capabilities  of  the  ALC  prototype.  A 
dedicated  graphics  workstation  should  eliminate  this  problem  providing  the 
;er  with  a  more  reponslve  system. 

Display  representations  could  also  be  enhanced  by  providing  a  thnt 
(imensional  extensioa  Currently  only  two  dimensional  design 
^presentations  are  supported.  A  three  dimensional  extension  would 
broaden  the  scope  of  possible  design  representations  that  could  be 
upported  by  such  an  environment 

As  more  and  more  military  software  systems  are  being  implement*  '  In 
Ada,  It  might  be  warranted  to  translate  the  current  implementation  to  Ada 
to  provide  a  better  Integration  with  other  software  packages.  Although  Ada 
joftware  can  be  designed  using  an  object-oriented  approach  [Booch,  1 986], 
the  object-oriented  nature  of  the  design  Is  lost  in  implementation  Ada 
toes  not  directly  support  an  object-oriented  Implementation  schema  such  as 
Smalltalk,  or  the  environment  Implemented  tn  this  thesis.  Recent  efforts  to 
^rovlde  an  object-oriented  framework  tn  Ada  has  met  with  some  degree  of 
success,  yet  a  complete  object-oriented  Implementation  of  Ada  looks 
»  jubtful  [Braaten  and  Hanson,  19861.  As  such,  some  of  the  object  oriented 
nature  of  the  ALC  prototype  Implementations  will  have  to  be  compromised 
for  an  Ada  Implementation. 

Long  Term.  The  long  term  recommendations  presented  here  pertain 
more  to  the  AC/CSRL  project  as  a  whole,  rather  than  individual 
enhancements  to  the  ALC  prototype.  The  recommenctei  tons  identified  during 
L.iis  thesis  effort  should  be  considered  as  possible  requirements  for  the 
AC/CSRL's  ALC. 
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When  testing  the  layout  capability  of  the  Layout  Editor,  It  was  often 
noticed  that  different  layouts  could  be  constructed  In  which  the  layout 
representation  could  not  be  matched  by  Its  corresponding  implementation  In 
the  real  world.  For  example,  the  aircraft  ordnance  loading  layout  (Figure  13) 
allows  aircraft  to  be  configured  with  different  type  of  missiles.  In  a  real 
aircraft  cockpit,  this  display  type  would  actually  represent  the  aircrafts' 
current  ordnance  status.  As  such,  there  Is  fixed  physical  limit  to  the 
amount  and  type  of  ordnance  that  a  specific  aircraft  can  deploy.  The  ALC 
Implemented  as  part  of  the  AC/CSRL  should  provide  some  means  of 
determining  If  a  cockpit  layout  Is  valid.  Design  verification  could  be 
achieved  by  integrating  a  knowledge  base  with  the  graphics  editor  used. 

Another  feature  not  implemented  as  part  of  the  ALC  prototype,  which 
should  be  Incorporated  In  the  AC/CSRLs'  ALC,  Is  the  capability  to  describe 
object  behavior.  It  Is  not  enough  Just  to  be  able  to  describe  an  object's 
form,  the  designer  should  also  be  able  to,  from  the  ALC,  describe  an  object's 
behavior.  The  definition  of  an  objects  behavior  could  Include  spatial 
contratnts  (l.e.  vertical  or  horizontal  movement)  and  Identification  of  which 
responses  from  the  Intended  environment  invoke  a  reply  from  the  object. 
From  such  definitions,  It  should  be  possible  to  generate  application 
software  to  dynamically  model  the  layout.  Related  work  In  this  area  Is 
currently  being  conducted  by  (Foley  and  Md1ath,1986]  and  [Hotlan  et. 
al.,  19841 


Conclusions  and  Recommendations  87 


Appendix  A:  Design  Methodologies 


Software  design  can  be  viewed  as  a  decomposition  process  guided  by  an 
abstraction  criteria.  The  decomposition  process  divides  the  original  problem 
space  into  a  series  of  smaller,  simpler  problem  spaces  while  abstraction 
guides  the  process  by  Imposing  restrictions  on  how  the  problem  space  is 
divided.  The  choice  of  the  abstraction  criteria  directly  Impacts  the 
structure  of  the  final  design. 

Traditionally  two  forms  of  abstraction  criteria  have  been  applied  to 
the  decomposition  process:  functional  (process-driven)  and  data-structure 
(data-driven).  Functional  decomposition  techniques  have  been  popularized  by 
practices  known  as  top-down  design.  Structured  Design  [Constantine  and 
Yourdon,  19791,  and  step-wise  refinement  [Wirth,197IJ.  These  techniques 
approach  decomposition  based  on  an  algorithmic  or  functional  view  of  the 
problem  domain  [Booch,  1986:21 1].  Large,  complex  problems  are  divided  into 
a  series  of  smaller  more  managable  subproblems.  These  subproblems  are 
solved  or  further  decomposed  Into  a  series  of  even  smaller  subproblems. 
Decompositon  is  repeated  until  the  entire  problem  is  stated  in  terms  of 
smaller,  solvable  subproblems.  The  subproblems  solutions  are  then  combined 
to  solve  the  original  problem. 

The  program  structure  derived  from  functional  decomposition  embodies 
a  hierarchical  refinement  of  functional  detail.  Each  level  of  the  hierarchy 
expresses  an  abstract  definition  of  system  functionality.  The  top  most  level 
defines  ’what'  the  system  should  do.  Succeeding  levels  refine  this  definition 
until  the  most  fundamental  operations  are  defined.  Each  fundamental 
operation  specifies  ‘how’  a  particular  function  in  the  system  performs.  By 
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combining  these  operations  under  a  hierarchical  network  of  control  flow  a 
hierarchical  program  structure  of  functional  components  is  created 

A  second  approach  to  software  design  decomposes  the  problem  space 
based  on  a  data-structure  abstraction.  Methods  developed  by  Jackson 
[Jackson J  9831  and  Wamier  [Wamler,  19771  are  the  most  popular.  These 
methodologies  subscribe  to  the  idea  that  the  "structure  of  a  software 
system  should  reflect  the  structure  of  the  data  processed  by  that  system" 
[Sommervi  lie,  1 985:691  Instead  of  decomposing  the  problem  space  based  on 
how  the  system  functions  (i.e.  functional  decomposition),  the  problem  space 
is  decomposed  based  on  an  analysis  of  the  Input  and  output  of  the  system 
data  This  decomposition  results  in  a  hierarchical  definition  of  the  data 
structures  that  reflect  the  data  processed  by  the  system.  The  program 
structure  is  formated  by  transforming  the  hierarchy  of  data  structures  Into 
a  hierarchy  of  corresponding  program  units  that  process  the  data 

Traditional  software  design  methodologies  provide  for  the  formulation 
of  problem  domain  representations  (designs)  based  on  either  a  functional  or 
data-structure  viewpoint.  Functional  decomposition  techniques  have 
concentrated  on  defining  the  operations  In  the  problem  domain  with  little 
regard  to  the  data  structures  needed.  On  the  other  hand,  data-structure 
decomposition  techniques  have  taken  just  the  opposite  approach.  The 
data-structures  are  defined  first;  functions  are  defined  as  an  afterthought 
to  use  the  structures.  Program  structures  generated  by  these  techniques 
seldom  portray  a  clear  and  direct  representation  of  the  problem  domain.  The 
program  structure  ends  up  representing  a  set  of  operators  (functions)  or  a 
set  of  operands  (data)  (Cox,  1984:581  A  synthesis  of  function  and  data  Is 
absent.  This  causes  the  program  structure  to  be  a  transformation  of  the 
problem  domain  rather  than  a  direct  mapping  of  It.  The  program  structure 
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becomes  "removed  from  the  problem  space"  [Booch, 1983:401 

An  alternative  to  the  more  traditional  software  design  methodologies 
(l.e.  functional  and  data-structure)  is  based  on  an  object-oriented  approach. 
Object-Oriented  Design  (OOD)  is  a  software  design  technique  in  which 
"decomposition  Is  based  upon  the  concept  of  an  object"  [Booch,  1986:21 11 
Objects  encapsulate  both  the  state  (data-structure)  and  behavior  (function) 
of  entitles  In  the  problem  domain  (Cox,1 984:571  A  synthesis  of 
data-structure  and  functionality  Is  achieved. 

The  Idea  of  combining  data  and  function  as  a  single  decomposition 
criteria  Is  rooted  In  the  principle  of  'Information  hiding'  tPamas,  19721 
Information  hiding  conceals  the  Internal  processing  details  of  Individual 
levels  of  the  program  structure  from  each  other.  Each  level  has  access  only 
to  Information  that  is  pertinent  to  Its  processing  needs.  Access  to 
Information  from  other  levels  Is  prohibited  Each  level  encapsulates  Its  own 
data  structure  and  operations.  Levels  communication  through  well-defined 
interfaces.  Knowledge  about  a  levels'  Internal  processing  details  are  hidden 
from  the  calling  level,  only  the  Interface  syntax  is  visible. 

The  value  of  OOD  arises  from  information  hiding.  Objects  are  abstract 
entitles  containing  both  state  (data)  and  behavior  (operations).  Every  object 
hides  its  internal  details  from  other  objects  and  communicates  via  message 
passing  (well-defined  Interfaces).  Objects  provide  an  abstraction  medium 
for  consolidating  the  ideas  of  information  hiding.  Program  structures  that 
were  once  transformations  of  the  probl  "  domain  (1  o.  ?ets  of  operands  or 
sets  of  operators)  are  now  composed  of  o^ects  (operands  and  orators) 
Decomposition  Is  viewed  as  an  Identification  pivm  Objects  are  identified 
In  the  problem  domain  and  mapped  directly  Into  the  struct 

Functionality  and  data-structure  are  no  longer  viewed  as  separate 
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attributes  of  the  problem  domain  ‘As  a  result,  the  designer  Is  not  forced  to 
restate  his  problem  In  computer-domain  terms,  where  everything  must  be 
either  an  operator  or  an  operand"  [Cox, 1984:58],  but  rather  defines  the 
design  In  terms  that  exist  in  the  problem  domain 

Basically,  OOD  can  be  generalized  In  the  following  four  steps: 

1 )  Definition,  examination  of  the  problem  domain, 

2)  Identification  of  the  objects  in  the  problem  domain, 

3)  Identification  of  operations  performed  on  the  objects,  and 

4)  Implementation  of  the  objects. 

[Booch,  1986:2 13;  Buzzard  et  al., 1985:1 1;  Cox,l984S8] 

The  first  step,  problem  definition,  is  common  to  all  design 
methodologies.  Its  goal  is  to  define  a  complete  and  understandable 
description  of  the  problem  domain. 

The  second  and  third  steps  in  the  OOD  process  involve  the  Identification 
of  objects  and  associated  operations.  The  procedure  for  doing  this  seems 
more  of  an  art  than  a  science.  Depending  on  the  complexity  of  the  problem 
domain,  the  task  of  object  and  operation  identification  may  be  Intuitively 
obvious  or  seemingly  impossible. 

Attempts  to  formalize  the  identification  process  have  been  popularized 
by  methods  proposed  by  Abbott  [Abbott,  1983]  and  Booch  [Booch,  1 9831  Their 
strategy  is  based  on  identifying  objects  and  associated  operations  by 
extracting  noun  and  verb  constructs  from  a  natural  language  description  of 
the  problem.  Objects  are  associated  with  noun,  pronouns,  and  noun  clauses, 
v.MIe  operations  are  associated  with  verbs,  verb  phrases,  and  predicates 
[EV8, ;  985:  2-6,2-91  Proponents  of  the  strategy  claimed  to  have  used  this 
technique  successfully  for  small  to  medtum  sized  (up  to  30,000  lines  of 
c^de)  programs  [EVB,  1 985: 1  -21  Yet  skepticism  remains  about  the 
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applicability  of  such  a  method  for  large  complex  programs  and  whether  a 
natural  language  description  cm  produce  a  clear  and  concise  enough 
description  of  the  problem  domain  for  this  technique  to  be  used 
[Sommervi  lie,  1 985: 94]. 

The  final  step,  Implementation,  performs  the  actual  mapping  of  the 
design  into  software.  The  degree  to  which  the  software  retains  Its 
object-oriented  structure  depends  directly  on  the  language  used  for 
implementation. 
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Appendix  B:  Characteristic  and  Terminology  Associated  with 

Oblect-Orfented  Systems 


This  appendix  provides  an  introduction  to  the  characteristics  and 
terminology  associated  with  object-oriented  systems.  This  appendix  Is  not 
intended  to  be  a  tutorial  on  the  subject,  but  rather  a  consolidation  of  terms 
and  characteristics  found  throughout  this  thesis.  Specifically,  this 
appendix  addresses  three  main  concepts  associated  with  object-oriented 
systems;  namely,  class,  message  passing,  and  inheritance. 

Classes 

Objects  are  the  sole  Inhabitants  of  an  object-oriented  environment. 
They  encapsulate  the  properties  of  data  (operands)  and  procedures 
(operators)  into  a  cohesive  whole.  The  data,  or  Instance  variables  define 
the  instrlnsic  properties  of  the  object.  For  example,  a  line  object  may 
contain  Instance  variables  that  describe  its  form  as  two  end  points, 
start  lng_endLpotnt  and  terminating_end_polnt.  The  instance  variables 
defined  for  an  object  are  only  known  to  that  object. 

Objects  also  contain  procedures  or  methods.  They  are  the  sole  means 
of  manipulating  an  object's  instance  variables.  Only  those  methods  defined 
for  an  object  can  manipulate  that  object's  Instance  variables.  Methods 
defined  In  other  objects  are  forbidden  from  directly  modifying  instance 
variables  of  different  objects. 

Objects  are  Implemented  as  Instances  of  classes.  Classes  serve  as  a 
'blueprint'  for  constructing  all  objects  in  the  system.  All  objects  are  an 
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Instance  of  a  single  class;  however,  classes  can  have  multiple  Instances  (t.e. 
objects).  For  example,  the  class  Rectangle  defines  all  the  information 
necessary  for  creating  a  rectangle.  Instances  of  the  class  Rectangle  would 
define  a  set  of  different  size  rectangles.  Each  rectangle  has  in  common  the 
property  of  'rectangleness',  yet  they  differ  In  their  presentation  (i.e.  size). 
Classes  capture  the  ‘gestalt-nesB’  of  the  instances. 

Classes  consist  of  class  variables  and  storage  for  the  Instance 
methods.  Class  variables  differ  from  Instance  variables,  in  that,  class 
variables  are  shared  by  all  the  Instances  of  the  class.  In  contrast,  each 
instance  maintains  Its  own  Instance  variables  and  has  exclusive  access  to 
them. 

Besides  class  variables,  each  class  maintains  the  actual 
Implementation  of  the  Instance  methods.  In  principle,  every  Instance  of  a 
class  could  maintain  a  personal  copy  of  the  methods;  however,  this  strategy 
Is  wasteful  (memory)  and  serves  no  useful  purpose.  By  confining  the  actual 
Implementation  of  the  methods  to  the  class  definition,  memory 
requirements  are  minimized  since  all  instances  share  the  same  methods. 
Viewed  In  this  way,  a  class  can  be  thought  of  as  collections  of  objects  that 
have  the  same  operations  In  common  [Curry  and  Ayers,  1984:5201 

Mwaige  EmlDtt 

Objects  communicate  via  a  message  passing  paradigm.  Instead  of 
directly  invoking  a  procedure  (operator)  to  perform  an  operation  on  an 
object,  one  sends  a  message  to  that  object.  The  receiving  object  determines 
how  to  handle  the  message.  The  receiver  has  three  options  available  to  it; 
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1)  It  can  Invoke  one  0/  tts  methods  to  implement  the  message, 

2)  It  can  Ignore  the  message,  or 

3)  It  can  pass  the  message  on  to  another  object. 

in  either  case,  the  sender  has  no  control  over  ‘how*  or  'who'  finally 
processes  the  message.  The  sender  blindly  trusts  that  the  receiver  will  do 
‘the  right  thing'  [Rentsch,  1982:54].  The  messages  that  an  object  responds  to 
defines  the  object's  interface  to  the  rest  of  the  system. 

The  principle  that  makes  message  passing  possible  Is  binding.  Binding 
is  the  act  of  translating  the  application  software  into  actual  machine 
addresses  for  execution.  There  are  two  basic  forms  of  binding,  static  and 
dynamic  [Aho  and  Ullman,  1 979:371  Static  binding  is  usually  performed  at 
compile  time.  The  software  is  bound  to  actual  machine  address  prior  to 
execution.  This  method  is  very  efficient,  binding  all  functions/procedures  to 
a  specific  data  type.  It  becomes  impossible  to  use  a  procedure  to 
manipulate  integers  on  one  line  then  use  that  same  procedure  to  manipulate 
strings  on  the  next  line.  The  procedure  must  be  explicitly  defined  with  an 
appropriate  data  type  and  used  with  that  data  type  consistently  throughout 
the  software.  On  the  other  hand,  dynamic  binding  delays  the  type  checking 
until  run  time.  It  becomes  the  responsibility  of  the  software  environment 
to  determine  how  to  handle  multiple  data  types,  making  it  possible  for  a 
procedure  to  manipulate  different  data  types. 

Object-oriented  systems  use  some  form  of  dynamic  binding  to  support 
message  passing.  Messages  are  sent  to  objects  to  elicit  a  desired  action. 
Since  the  message  content  is  not  checked  -inti  I  run-time,  multiple  objects 
can  be  sent  the  same  message.  It  then  becomes  the  responsibility  of  the 
receiving  object  to  determine  how  to  interpret  the  message.  For  example, 
the  message  'draw'  would  elicit  a  different  response  from  a  Line  object  than 
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tt  would  from  a  Circle  object.  Both  objects  would  Interpret  the  message 
and  perform  the  appropriate  draw  response.  The  meaning  and  syntax  of  the 
message  Is  the  same  for  both,  but  the  means  in  which  the  message  is 
Implemented  is  dependent  upon  the  object  that  receives  it.  The 
reponsiblllty  of  implementing  the  message  rests  squarely  with  the 
receiving  object. 

iDhirltinci 

Object-oriented  systems  also  support  a  concept  known  as  inheritance. 
Inheritance  is  a  means  of  creating  specializations  of  existing  classes.  The 
new  class,  known  as  the  subclass,  inherits  alt  the  class  variables,  instance 
variables,  and  methods  of  the  existing  class,  or  superclass  The  subclass  is 
distinguished  from  its  superclasss  by  unique  class  variables,  instance 
variables,  and  methods.  Methods  defined  in  the  subclass  may  override  the 
methods  inherited  by  the  superclass  or  can  be  used  to  enhance  the 
superclass  methods.  {Pascoe,  1 986: 1 42] 

There  are  two  basic  forms  of  inheritance,  hierarchical  and  multiple 
(Stef ik  and  Bobrow,  1 986:46-49],  Hierarchical  inheritance  is  the  simplest  of 
the  two.  It  restricts  the  number  of  classes  that  a  subclass  may  inherit  to 
one.  Each  subclass  in  the  hierarchical  scheme  has  only  one  superclass.  This 
results  in  an  inheritance  structure  similar  to  a  tree  in  which  each  node  is 
the  decendent  of  only  one  previous  node.  Multiple  inheritance,  one  the  other 
hand,  allows  multiple  classes  to  be  inherited  by  a  single  subclass.  This 
results  ?n  3  tre.i  structure  in  which  a  node  can  be  descendant  from  one  or 
more  other  nudes.  Figure  16  illustrates  this  difference. 
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When  viewing  inheritance  diagrams,  it  ts  important  to  understand 
which  direction  the  Inheritance  follows.  Upon  Initial  Inspection,  one  would 
assume  that  class  A,  would  inherit  characteristics  from  both  B  and  C.  In 
inheritance  diagrams,  such  as  Figure  16,  this  ts  just  the  opposite.  It  is 
classes  B  and  C  that  inherit  characteristics  from  A  In  the  hierarchical 
example,  each  class  inherits  characteristics  from  only  one  other  class.  In 
the  multiple  Inheritance  example,  class  F  Inherits  characteristics  from 
both  B  and  C. 

The  choice  of  which  inheritance  mechanism  ts  used  will  often  depend 
on  the  class  structure  of  the  application.  For  applications  where  classes 
are  mostly  independent  of  each  other,  a  hierarchical  inheritance  structure 
could  suffice.  However,  in  applications,  where  classes  are  highly 
interrelated,  the  use  of  a  multiple  Inheritance  structure  Is  warranted. 
Multiple  Inheritance  structures  provide  an  extra  level  of  flexibility  not 
usually  associated  with  strlct’y  hierarchical  structures,  Since  classes  in  a 
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multiple  Inheritance  structure  can  Inherit  multiple  classes,  adding  new 
classes  is  simply  a  matter  of  establishing  new  Inheritance  links  to  the 
existing  structure.  Adding  new  classes  to  a  hierarcf.  cal  stucture  could 
entail  a  readjustment  of  the  entire  structure. 
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Appendix  C:  An  Object-Oriented  Extension  of  the  T"  Language 


This  appendix  describes  an  object-oriented  extension  of  the  C' 
language  that  was  implemented  as  part  of  this  thesis.  It  differs  from 
previous  object-oriented  extensions  of ‘C‘,  [Stroustrup,  1 983]  and  [Cox,  1983], 
in  that  it  does  not  require  the  code  to  be  pre-compiled.  All  extensions  are 
implemented  in  standard  *C.  This  should  make  this  implementation 
transportable  to  other  V  systems. 

Three  primary  extensions  were  added,  namely;  class  type,  message 
passing,  and  multiple  inheritance.  The  models  for  these  extensions  were  the 
Smalltalk  language  [Goldberg  and  Robson,  1983]  and  Traits  [Curry  and 
Ayers,  19841  A  description  of  these  extensions  is  provided  in  the  following 
sections. 

Claaasa 

The  class  concept  is  implemented  as  a  data  structure  consisting  of 
three  interrelated  components;  object,  class,  and  method  table.  Each 
component  is  implemented  with  an  identical  'C  structure  (Figure  17).  Each 
node  In  the  structure  consists  of  six  fields.  The  first  field,  type,  identifies 
the  component  for  which  the  node  is  being  used.  The  second  field,  ptr__type, 
provides  a  generic  means  of  assigning  the  different  components  to  the  node. 
Field  three,  super,  supports  the  concept  of  inheritance  by  serving  as  a  link 
to  other  class  nodes.  The  fourth  field,  path,  is  used  to  link  the  different 
components  together.  The  fifth  and  sixth  fields,  next  and  back,  are  used  by 
the  system  to  construct  component  lists  of  object  and  class  types. 


Appendix  C 


99 


Figure  17.  Generic  Node  Structure. 


Object  Mode:  An  object  node  represents  an  actual  Instance  of  a  class. 
Multiple  object  nodes  can  be  instantiated  for  a  single  class.  Each  object 
node  Instantiated  shares  all  the  class  variables  and  methods  defined  for  the 
class.  However,  the  Instance  variables  associated  with  an  object  node  are 
private  to  that  node. 

Objects  are  Instantiated  dynamically  at  run-time.  The  application 
program  will  typically  send  a  message  to  a  class  requesting  the  creation  of 
an  object.  The  class,  in  turn,  will  invoke  the  appropriate  class  method  to 
allocate  storage  from  the  memory  heap  for  the  object.  The  new  object  is 
then  linked  to  the  class  node.  A  handle,  or  pointer,  is  returned  to  the 
application  Identifying  the  new  object.  Objects  can  also  be  deleted  from  the 
system  in  opposite  manner  by  nulling  Its  pointers  and  deallocating  its 
storage  from  memory. 


Class  Itodft  Class  nodes  are  the  foundation  of  the  data  structure.  All 
object  nodes  are  linked  to  class  nodes.  There  exists  a  many  to  one  mapping 
between  object  nodes  and  class  node.  Only  one  class  node  Is  associated 
with  an  object  nodes.  Class  nodes  provide  the  common  channel  for  all 
method  Invocation. 

All  classes  are  Instantiated  are  run-time  by  the  function  setupO. 
SetupO  allocates  storage  for  each  class  node  and  assigns  global  pointers  for 
each  class.  These  pointers  are  used  by  applications  to  identify  the  class  in 
which  they  want  an  instance.  SetupO  should  be  the  first  function  called  by 
the  application  and  It  should  be  called  only  once. 

Method  Table  Node:  The  method  table  node  provides  access  to  the 
methods  associated  with  a  class.  Methods  are  maintained  in  a  linked  list 
structure.  Each  node  In  the  list  contains  a  selector;  to  Identify  the  method,  a 
parameter  count,  and  the  actual  machine  address  of  the  ‘C‘  function  that 
Implements  the  method.  Figure  18  Illustrates  the  linked  list  structure  of 
the  method  table.  The  method  table  node  and  list  structure  Is  Instantiated 
automatically  when  the  class  node  Is  Instantiated. 

The  inter-relationship  of  object,  class,  and  method  table  nodes 
Illustrated  In  Figure  19  represents  the  system  structure  containing  a  single 
class.  As  more  classes  are  added,  the  system  structure  takes  on  the  form  of 
a  tree  (Figure  20)  where  each  node  In  the  tree  represents  the  structure  as 
presented  in  Figure  19.  The  branches  In  the  tree  form  the  inheritance  chain 
between  classes.  All  inheritance  in  the  tree  terminates  in  a  single  node  or 
class.  This  class  is  commonly  refered  to  as  Object.  The  class  Object  is  the 
only  class  In  the  system  that  does  not  have  a  superclass. 


Appendix  C 


101 


.Vi 


Figure  18.  Method  Table  Structure. 
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Figure  20.  Structure  of  Multiple  Classes. 


Message  Passing 

All  objects  Interact  via  message  passing.  Essentially,  message  passing 
Is  a  form  of  Indirect  runctlon  Invocation.  Instead  of  directly  Invoking  a 
function,  as  is  done  in  Ada  or  Pascal,  a  message  is  sent  to  an  object  for 
processing.  The  receiving  object  then  determines  how  the  message  is 
handled,  not  the  sender. 

Message  passing  Is  performed  via  two  C  functions,  msgO  and 
broadcast_ta_super().  MsgO  is  the  primary  way  of  sending  messages  to  an 
object.  MsgO  supports  message  passing  directly  to  a  different  object  or 
allows  a  message  to  be  sent  to  Itself.  Broadcast_to_superO  allows  a 
message  to  be  sent  Immediately  to  the  objects  superclass  by  bypassing  the 
object’s  methods. 
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Both  procedures  employ  the  same  parameter  passing  order  or  protocol. 
The  protocol  of  each  function  consists  of  a  receiver,  the  message  (or 
selector),  and  any  parameters  associated  with  the  message.  The  receiver  is 
the  object  In  which  the  message  is  intended  for.  The  receiver  may  be  a 
different  object  than  the  sender  or  the  sender  may  send  Itself  a  message.  In 
either  case,  the  message  must  always  be  addressed  to  an  object.  The 
system  currently  performs  little  errror  checking.  Any  attempt  to  send  a 
message  to  a  non-existent  object  will  most  likely  cause  the  application  to 
crash. 

The  selector  is  the  actual  message  text,  character  string,  that 
Indicates  which  method  should  be  invoked  by  the  receiving  object.  Each 
message  can  have  up  to  five  associated  parameters.  These  parameters  can 
be  any  of  the  following  data  types :  char,  int,  float,  and  node-type. 

Examples  of  message  passing  follows: 

msgt  cfrcle,"setRadlu8",20); 

This  example  Illustrates  a  message  being  sent  to  the  object  'circle'. 
The  sending  object  has  requested  that  'circle*  change  Its  radius  to  20.  If  the 
message  had  been: 

msg(  circle, ’Radlus',20); 

Circle  woula  have  Ignored  it  and  retained  it  original  radius  value  since 
'circle'  does  not  understand  what  "Radius"  means.  It  thus  becomes  very 
Important  to  send  the  correct  format  of  the  message  to  the  object  to  ensure 
that  the  desired  action  Is  performed. 
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MsgO  also  has  the  capability  of  returning  a  response  from  an  object.  In 
such  cases,  the  sender  must  know  beforehand  the  format  of  the  reply,  for 
example,  if  sender  requests  the  circle  radius: 

radius  -  (lot)  msg(  circle, 'getRadfus"); 

The  sender  must  know  in  advance  that  the  result  will  be  of  'Int*  type.  The 
sender  should  not  expect  something  different.  More  complex  formats  can 
also  be  returned  from  msgO,  for  example: 

new_rirc1e  -  (node_type  *)  msg(c1rcle,*clone‘); 

returns  a  pointer  to  a  copy  of  the  original  'circle1  object. 

Broadcast_to_superO  does  not  provide  a  reply  capability.  Thus  it  should 
only  be  used  for  messages  that  generate  no  response. 

MultlPlf  Infurftmct 

Having  described  how  message  passing  is  performed  on  the  conceptual 
level,  it  is  now  worthwhile  to  Investigate  how  message  passing  is  handled 
by  the  system  Who!,  an  object  receives  a  message,  it  scans  Its  method 
table  comparing  the  selector  passed  to  It  against  selectors  stored  in  the 
method  table.  If  a  match  is  made,  the  ’C'  function  associated  with  that  entry 
is  Invoked.  If  no  match  is  found,  the  object  has  one  of  two  options.  It  can 
simply  Ignore  the  message  and  return  control  back  to  the  sender,  or  It  can 
pass  the  message  on  to  its  superclass. 
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An  object  can  ignore  a  message  only  if  it  has  no  superclass  to  pass  the 
message  on  to.  Since  the  class  Object  is  the  only  class  with  no  superclass, 
it  is  the  only  class  the  is  allowed  to  ignore  a  message. 

Passing  the  message  on  to  an  objects  superclass,  cause  the  superclass 
to  search  its  method  table.  If  no  match  is  found,  the  message  is  passed  on  to 
the  superclasses’  superclass,  or  the  original  receiving  objects 
super-superclass.  This  recursive  procedure  continues  until  a  match  is  found 
or  until  Object  receives  the  message.  If  Object  can  match  the  message  In  its 
method  table,  the  function  is  invoked,  otherwise  the  message  Is  ignored  and 
control  Is  return  to  the  sending  object 

The  ability  of  an  object  to  pass  on  a  message  to  a  superclass  Is  the 
basis  for  inheritance.  When  a  message  Is  processed  by  the  superclass,  the 
original  Instance  is  said  to  Inherit  that  supperclass's  method.  Even  though 
the  method  that  Implemented  the  message  is  not  defined  In  the  objects 
method  table,  it  can  be  used  as  if  it  were.  When  an  object  only  inherits 
methods  from  a  single  superclass,  Inheritance  is  viewed  as  hierarchical.  All 
classes  In  the  inheritance  chain,  Inherit  the  methods  of  only  one  superclass, 
and  that  superclass  inherit  methods  from  only  one  super-superclass,  so  on 
and  so  on  until  the  Object  class  Is  reached. 

Multiple  Inheritance  allows  a  Jar?  to  Inherit  methods  from  multiple 
superclasses.  The  superclasses  can  then  Inherit  methods  from  multiple 
superclasses,  so  on  and  so  on,  until  ail  inheritance  terminates  with  the 
Object  class. 

A  multiple  Inheritance  schema  was  chosen  for  this  implementation.  To 
support  multiple  inheritance  a  precedence  list  was  established  for  each 
object  (the  field  'super'  in  the  object  node  points  to  this  list).  This  list 
keeps  track  of  all  the  superclasses  associated  with  an  object.  When  a 
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message  is  sent  to  an  object,  the  object's  method  table  is  searched.  If  does 
not  contain  the  method,  the  method  table  of  the  first  superclass  in  the 
precedence  list  is  searched.  If  the  search  fails,  the  method  table  of  the  first 
superclass  in  the  current  superclass  precedence  list  Is  searched.  This 
continues  until  the  Object  class  Is  reached.  The  class  Object  is  represented 
by  a  precendence  list  that  points  to  NULL  When  a  NULL  Is  encountered, 
control  is  return  to  the  previous  superclass  and  the  next  class  In  the 
precedence  list  Is  searched.  This  continues  until  a  match  Is  found  In  one  of 
the  superclass's  method  table  or  until  the  calling  object  is  returned  control. 

This  may  seem  a  bit  complicated  at  first,  but  as  more  and  more  classes 
are  added  to  the  system,  the  power  and  elegance  of  this  schema  to  absorb 
them  without  modifications  to  the  software  structure  becomes  evident. 
New  classes  are  simply  assigned  pointers  to  the  superclasses  In  which  they 
wish  to  establish  an  inheritance  with.  All  methods  associated  with  the 
superclass  are  made  accessible  to  the  new  class.  This  provides  a  high 
degree  of  software  reusability  among  the  classes. 
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Appendix  D:  Class  Descriptions 


This  appendix  describes  the  Interface  for  all  currently  Implemented 
classes.  Figure  21  Illustrates  the  Inheritance  relationship  among  these 
classes.  These  classes  are  divided  Into  three  categories;  1)  graphic 
primitives,  2)  user  Interface,  and  3)  miscellaneous.  The  graphic  primitives 
are  classes  that  describe  basic  graphic  entities  such  as  rectangle,  circle, 
and  polygon.  The  user  Interface  consists  of  classes  that  support  the  ALC 
prototype  user  Interface.  The  miscellaneous  classes  provide  support  for  the 
other  two  class  categories. 

Classes  are  described  in  terms  of  variables  and  methods.  Specifically, 
each  class  provides  the  following  information: 


1.  Class  Name 

2.  Superclass:  The  superclass(s)  identify  those  classes  that  are 

Inherited  by  the  current  class.  All  class  variable,  instance 
variables,  class  methods,  and  instance  methods  defined  for  a 
superclass  are  inherited  by  the  current  class. 

3.  Class  Variables:  Defines  those  variables  that  are  unique  to  the 

class  and  shared  by  all  instances  of  that  class. 

4  Class  Methods:  The  methods  (operations)  that  are  uniquely  defined 
for  the  class.  The  ’C’  Interface  for  each  method  is  provide. 

5.  Instance  Variables:  Defines  those  variables  that  are  private  to 

each  Instance. 

6.  Instance  Methods:  The  methods  that  are  available  to  an  Instance. 

The  V  Interface  of  each  method  Is  provided. 
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Graphic  Primitives 
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Class:  circle 

Super  Class:  graphic  primitive 

CI888  Variables:  none 
Class  Methods: 
new 

function:  Instantiates  a  circle  object 
circle  •  (node-type  *)  msg(  circle-class, "new" ) 

Instance  Variables: 

radius  :  defines  the  radius  of  the  circle. 

loatinca.MaUmla; 

clone 

function:  Answers  with  a  clone  of  an  existing  object, 
object-clone  «  (node-type  *)  msg(  circle/clone" ) 

8etClrcle 

function:  Defines  where  the  circle  is,  and  its'  size. 
msg(  circle,"setClrcle",[x],ly], [radius] ) 

setRadlus 

function:  Defines  the  size  of  the  circle. 
msg(  circle, "setRadlus”, [radius] ) 

scaleBy 

function:  Scales  the  circle  in  both  the  x  and  y  directions. 
msg(  circle, "scaleBy", [factor] ) 

draw 

function:  Draws  the  circle. 
msg(  circle, "draw" ) 
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Internals 

function:  Prints  the  circles'  Instance  variables. 
msg(  circle/internals" ) 
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Class;  graphic-primitive 


;  object 


Cilia  Virllblis;  none 
Class  Methods: 


function:  instantiates  a  graphic  primitive  object 

primitive  »  (nodeu-type  *)  msg(  graphic-primitive-class/new" ) 


'a'. 


:.v.l 


cx,cy  :  center  point  of  graphics  primitive 
color  :  color  of  graphic  primitive 
solfdFill  :  flag  indication  whether  primitive  should  be  solid  filled 
drawhode:  determfse  how  the  image  Is  drawn  on  the  screen 
(l.e.  normal  or  XOR) 

area  :  area  of  graphic  primitive  in  pixels 
extent  :  the  graphic  primitives  extent  on  the  screen.  The  extent 
is  defined  as  a  rectangluar  region. 


area 

extent 


.•;v . 

J 

•  •  i'. 

i 


•  •  ( ■ 

•*'i 


clone 

function:  creates  a  clone  of  an  existing  object  Caller  is  returned 
a  handle  to  a  new  object 

clone-object  -  (node_type  *)  msg(  primitive/clone* ) 
setCotor 

function:  sets  the  color  of  the  graphic  primitive, 
msg ( primitive/setColor",  [COLOR] ) 


.'.ii*, 
« .  * 

,*V*1 


setSolldFfll 

function:  sets  whether  a  graphic  object  is  displayed  solid  filled. 
msg(  primltlve/setSolidFlir,  [TRUE  or  FALSE] ) 
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MtEXiMlt 

function:  sets  the  rectangular  extent  of  the  graphic  primitive.  The 
area  of  the  graphic  primitive  is  automatically  updated. 
msg(  primitive, “setExtent", [left],  [bottom],  [right],  [top] ) 

setDrawMode 

function:  Sets  the  drawing  mode  for  the  object 
msg(  primitive, "setDrawMode\[mode] ) 

gatCoior 

function:  Answers  with  the  primitives  color, 
color  -  (int)  msg<  primitive, "getColor" ) 

getSoiidFtli 

funciton:  Answers  with  the  primitives  solid  fill  status, 
fill  •  (Int)  msg(  primitive, "getSolldFil  I" ) 

getExtent 

funciton:  Answers  with  the  primitives  extent 
extent  -  (extent-type  *)  msg(  primittve/getExtent" ) 

getOrawMode 

function:  Answers  wih  the  primitives  drawing  mode, 
mode  ■  (int)  msg ( primitive, "getDrawMode“ ) 

i 

getArea 

function:  Answers  with  the  primitives'  area, 
area  -  (int)  msg(  primitive, "getArea* ) 

getCenterPoint 

function:  Answers  with  the  primitives  center  point, 
point  ■  (point-type  *)  msg(  primitive, ’getCenterPolrit" ) 

contalnsPoint 

function:  Answers  whether  the  primitive  contains  a  specific 
point  (TRUE  or  FALSE). 

reply  •  (Int)  msg(  primitive,‘contalnsPoint",[x],  (yj) 
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moveTo 

function:  Moves  (centers)  the  primitive  over  a  specific  point. 
msg(  primitive, "moveTo'MIyl ) 

showExtent 

function:  Displays  the  primitives'  extent 
msg ( prim  i  tlve, -showExtent’ ) 

hideExtent 

function:  Erases  the  primitives  extent 
msg ( primitive/hideExtent’ ) 

Internals 

function:  prints  the  instance  variables  of  the  primitive. 
msg(  primitive, "internals" ) 
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film;  line 

Super  Class:  graphic  primitive 
Claaa  Variable:  none 

cl«8a.nethQdg: 

new 

function:  Instantiates  a  line  object 

line  ■  (node-type  *)  msg(  lir>e_c lass/new* ) 


start_xJstart-y  :  the  starting  and  point  of  the  line. 
erxLx,  encLy  :  the  end  point  on  the  line. 

inatanct  Mttlwda? 

clone 

function:  Answers  with  a  clone  of  an  existing  object, 
object-clone  ■  (node-type  *)  msg(  line/clone" ) 

setLIne 

function:  Defines  the  end  points  of  the  line. 

msg(  Ilne/setLineMstart-xUstart-yUend-xUencLyl ) 

scaleBy 

function:  Scales  the  line  In  both  the  x  and  y  directions. 
msg(  1 1  ne, "seal  eByMf  actor] ) 


draw 

function:  Draws  the  line. 
msg(  line/draw* ) 

Internals 

function:  Prints  the  lines'  instance  variables. 
msg(  line/ interna  Is" ) 
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Class;  polygon 

Supt  Class:  graphic  primitive 
Class  Variables:  none 
Class  htthotis; 
new 

function:  Instantiates  a  polygon  object 
poly  ■  (node-type  *)  msg(  poly_c  I  ass/new" ) 


num-of-points  :  Number  of  points  that  define  the  polygon. 

Inatanct  ntUuhte 

clone 

function:  Answers  with  a  clone  of  an  existing  object 
object-clone  -  (node-type*)  msg( poly/clone" ) 

addToPoly 

function:  Adds  a  point  to  the  polygon 
msg(  poly/addT  oPolyMxUy] ) 

scaleBy 

function:  Scales  the  polygon  in  both  the  x  and  y  directions. 
msg(  poly/scaleBy"Mly] ) 


draw 

function:  Draws  the  polygon. 
msg(  poly/draw* ) 

Internals 

function:  Prints  the  polygons'  instance  variables. 
msg(  poly /’Internals" ) 
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rectangle 

Super  Class:  graphic  primitive 
Class  Variables:  none 

aiMflttlKHto 

new 

function  Instantiates  a  rectangle  object 
rect » (node-type  *)  msgtrect-class/new" ) 


left,bottom  :  lower  left  hand  comer  of  the  rectangle, 
right,  top  :  upper  right  hand  comer  of  the  rectagle. 

matinee  nt  tfuKte 

clone 

function  Answers  with  a  clone  o>  listing  object, 
object-clone  ■  (node-type  *)  msg(  rect, ‘clone" ) 

setRect 

function  Set  the  dimensions  of  the  rectangle. 
msg(  rect/setRectMleftUbottomUrightLItop] ) 

scaleBy 

function:  Scales  the  rectangle  In  both  the  x  and  y  directions. 
msg(  rect, "sea  leByMf  actor] ) 

draw 

function  Draws  the  rectangle. 
msg(  rect, "draw' ) 

Internals 

function  Prints  the  rectangle's  instance  variables. 
msg(  rect,"  Internals' ) 
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Class:  text 

Sudt  Class:  graphic-primitive 


Class  Variable:  none 
CllMtltthOdS? 


new 

function:  instantiates  a  text  object 

text  ■  (node-type  «)  msg ( text-class, "new") 


length  :  Text  length  in  pixels, 

height  :  Text  height  in  pixels, 

size  :  Font  size, 

font  :  Style  of  font 

text-string  :  Actual  character  string. 

A 

v  instinct  nttlKHto 

clone 

function:  Creates  a  clone  of  an  existing  object.  Answers  with  a 
handle  of  the  new  object 
clone-object  •  (node-type  *)  msg(  text, "clone’ ) 

setText 

function:  Defines  text  as  a  string  of  characters. 
msg(  text,  "setText",  [  string  ] ) 

getTextSIze 

function:  Answers  with  the  current  size  of  text, 
size  -  (Int)  msg<  text/getTextSize" ) 

scaleBy 

function:  Scales  the  text  object  In  both  the  x  and  y  directions. 
msg(  text, "scaleBy",  [factor] ) 

# 
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start  writ*  At 

function:  Defines  the  location  where  the  lower  left  hand  comer 
of  the  text  should  begla 
msg(  text,"startWriteAt",Ixj,  ly] ) 


function:  Draws  the  text  string. 
msg(  text, "draw" ) 

Internals 

function:  Prints  the  instance  variables  of  the  text  object 
msg(  text,"  Internals" ) 
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^  Elm  commands 

Suaar  Class:  window 
text 


Claw  Variables:  none 

Class  tflhods: 


new 

function:  Instantiates  a  command  object 

command  •  (node-type  *)  msg(  command-class, "new" ) 


command-num  :  command  id 

Inatincf-Mathiwte; 

setCommand 

funclton:  Defines  the  command  box. 

msg(  command, "setCommand", (command  text  strlng],[command  Id] ) 

getCommand 

function-.  Answers  with  the  command  Id 
id  -  (int)  msg(  command, "getCommand" ) 

moveTo 

function:  Moves  (centers)  a  command  over  a  specific  point. 
msg(  command, "moveTo", lx],  ly] ) 

draw 

function:  Draws  a  command  box. 
msg(  command, "draw" ) 

internals 

function:  Prints  the  command  objects'  Instance  variables. 
msg(  command, "Internals" ) 
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^  Class:  cursor 

Super  Class:  object 
Class  Variables:  none 

CtMaJlittHHte 

new 

function:  instantiates  a  cursor  object 
cursor  -  (node-type  *)  msg<  cursor-class, "new") 


color 
status 
left,bottom 
right, top 


location  of  cursor 

color  of  cursor  bounding  box 

status  of  cursor  ON  or  OFF 

lower  left  hand  comer  of  cursor  bounding  box 

upper  right  hand  comer  of  cursor  bounding  box 


instinct  ramiMte 


setColor 

function:  sets  the  color  of  the  cursor's  bounding  box. 
msg(  cursor, "setColor",  ( COLOR  ] ) 

setCursor 

function:  define  the  cursors'  bounding  box. 
msg(  cursor, ‘setCursor’,  {an-objectl ) 

updataCursor 

function:  updates  the  cursors'  position  and  apperance. 
msg(  cursor/updateCursor" ) 

turnOn 

function:  turns  the  cursor  on.  Display  the  bounding  box. 
msg(  cursor, "tumOn" ) 
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turnoff 

function:  turns  the  cursor  off.  No  bounding  box  is  displayed. 
msg(  cursor/tumOff ) 

internals 

function:  prints  the  instance  variables  of  the  cursor  object. 
msg(  cursor/intemals* ) 
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Class:  dialogue 


Super  Class:  window 
text  list 
graphic  list 

Class  Variables:  none 

ciaaa  Mamma 


new 

function:  Instantiates  a  dialogue  object, 
dialogue  ■  (node-type  #)  msgtdlalogue-class/new") 


none 


inatinci  nttlwda? 

appendText 

function:  Adds  textual  information  to  the  dialogue. 
msg(  dialogue,  “appendText",  (text  string],  [font  size] ) 

appendCommand 

function:  Adds  command  boxes  to  the  dialogue. 

msg(  dialogue, "appendCommand“,[command  text],[command  ldl,[x],[y]) 

moveTo 

function:  Moves  (centers)  the  dialogue  object  over  a  specific  point. 
msg(  dialogue, “moveTo", (x),  [y] ) 


draw 

function:  Oraws  the  dialogue  box. 
msg(  dialogue, "draw" ) 

engagelnOialogue 

function:  Activates  a  dialogue  box. 
msg(  dialogue, "engagelnOialogue" ) 
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Internals 


function:  Prints  the  dialogues'  instance  variables. 
msg(  dialogue, "Internals’ ) 
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Class:  display  window 


Suptr  Class:  window 

graphic  list 

Class  Variable  none 

Cliaa  Mfltlwdi: 

new 

function:  Instantiates  a  display  window  object. 

dlSLWindow  -  (node-type  *)  msg(  dlsplay-window-jclass/new" ) 


Instance  Methods: 
update 

function:  Draws  ail  the  objects  contained  In  the  window. 
msg(  dis-window/update" ) 

Internals 

function:  Prints  the  display  window's  instance  variables. 
msg(  dls_window, "Internals* ) 
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Class:  mouse 
SUPff  C118S;  object 
Cliaa.Virlablea; 

x,y  :  location  of  mouse, 
button  :  active  buttonon  mouse. 

Class  Methods: 

track 

function:  Answers  with  the  mouses'  current  location, 
reply  ■  (mouse-even  t_type  *)  msg(  mouse-class/track" ) 

waltForEvent 

function:  Waits  until  a  button  is  pushed  Answers  with  the  mouses' 
location  and  button  number. 

reply  -  (mouse-event-type  *)  msg(  mouse-class," waltForEvent") 

getMouse 

function:  Answers  with  the  mouse's  current  location  and  button 

number  if  a  button  has  been  pushed,  else  button  number  is 
returned  as  zero. 

reply  >  (mouseuevent-type  «)  msgCmoust-class, "getMouse" ) 
clearMouse 

function  Resets  the  mouse  and  clears  any  queued  events. 
msg(  mouse-class, "clearMouse" ) 

Instance  Methods:  none 
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Class:  option 


Super  Class:  window 
Class  Variables:  none 
Class  Methods: 


MW 

function:  Instantiates  an  option  object 
option  •  (node-type  *)  msg(  optlon-class/new" ) 


none 


Instancs  Methods: 
hints 

function:  Changes  the  appearence  of  an  option. 
msg(  optlon/hiLite",  [ON  or  OFF] ) 

sstOption 

function:  Associates  an  object  with  the  option. 
msg(  option/setOptlonMobject] ) 

gstOptlon 

function:  Answers  with  a  handle  to  the  associated  object, 
object-handle*  (node-type *)  msg( option, "getOption") 

draw 

function:  Draws  the  option. 
msg(  option/draw* ) 

Internals 

function:  Prints  the  options  instance  variables. 
msg(  option/  Internals" ) 
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Qua?  option  window 


Shot  Class:  window 

graphic  list 

Class  Variables:  none 
Class  Methods: 
new 

function:  Instantiates  a  option  window  object 

opt-wtndow  ■  (node-type  *)  msg(  option-window-ciass/new" ) 


left,bottom  :  bottom  left  hand  comer  of  option  window, 
right  top  :  top  right  hand  comer  of  option  window, 
delta-x  :  displacement  of  the  window  along  the  x-axls. 

delta-y  :  displacement  of  the  window  along  the  y-axls. 

InatancttilttlMwte 

defineOptionWIndow 

function:  Defines  the  size  of  each  Individual  window. 

msg ( opL.wlndow/defineOptionWlndowMieft]1[bottom]J[rlght],[top]) 

addTo 

function:  Adds  an  option  to  the  option  window. 
msg(  opt-wlndow/addToMoptlonl ) 

moveTo 

function:  Moves  (centers)  the  first  option  over  a  specific  point. 

All  other  options  in  the  window  are  relative  to  this  point. 
msg(  opt-window/moveToMxijy] ) 

clear 

function:  Resets  the  option  window. 
msg(  opt-wlndow, "clear" ) 
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update 

function:  Answers  with  the  selected  option.  The  appearence  of  the 
opt  window  is  modified  to  reflect  the  selection, 
selection  -  (node_type  *)  msg(  opt_wlndow/update"M(y] ) 


draw 

function:  Draws  the  option  window. 
msg(  opt-wlndow,"draw" )  — 

Internals 

function:  Prints  the  option  window's  instance  variables. 
msg(  opt-wlndow, "Internals" ) 
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Class:  pull  down  menu 

Super  Class:  window 

graphic  list 

Claaa  Variable  none 
Claaa  Methods: 


new 

function:  instantiates  a  pull  doen  menu  object 

menu  -  (node-type  *)  msg(pull-down_menu-c  I  ass/new" ) 


none 


Inatmca  ntthote 

appendMenultem 

function:  Adds  a  menu  item  to  the  menu. 

msg(  menu/appendMenul  tem",[  i  tem  text],  [item  id] ) 

moveTo 

function:  Defines  (centers)  where  first  menu  item  is  drawn, 
msg ( menu/moveToMx],Iy] ) 


draw 

function:  Draws  the  pull  down  menu 
msg(  menu/draw") 

engagelnDlalogue 

function:  Maintains  the  cursor  within  the  menu. 
msg(  menu/engagelnDialogue" ) 

Internals 

function:  Prints  the  menus'  instance  variables. 
msg(  menu/  Internals" ) 


Appendix  D 


132 


Class:  window 
Super  Class:  rectangle 
CJm  ViriihUa:  none 
Class-Hethods; 

IMW 

function:  Instantiates  a  window  object 

window  -  (node-type*)  msg(  window-class, "new") 


backgroundcolor  :  color  of  the  windows'  background 
Instance  Methods: 

setBackgroundColor 

function:  Sets  the  windows'  background  color. 
msg(  wlndow/setBackgroundColoT,  (color! ) 

getBackgroundColor 

function:  Answers  with  the  windows'  background  color, 
color-  (tnt)  msg(wlndow, "getBackgroundColor’ ) 

setWIndow 

function:  Oef  Ines  the  window  size. 

msg(  window, "setWIndow",  HeftUbottomJ,[rlghtJ,Itop] ) 

clear 

function:  Clears  the  window  with  the  windows'  background  color, 
msg <  window, "clear" ) 

erase 

funciton:  Clears  the  windows  contents  and  frame  with  background 
color. 

msg<  window, "erase") 
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clip 

function:  Bounds  aii  drawings  inside  the  window. 
msg(  window/clip" ) 

Internals 

function:  Prints  the  windows'  instance  variables. 
msg(  window, "internals” ) 
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Miscellaneous 


Class:  graphics 
Super  Class:  object 
Class  Variables:  none 
Clu  WthadB; 

startup 

function:  Initializes  the  graphics  environment. 
msg(  graphlcsL^lass/startUp" ) 

shutOown 

function:  Exits  from  the  graphics  environment 
msgC  graphics-class/shutDown" ) 

setScreenMode 

function:  Sets  the  way  images  are  drawn  on  the  screen 
(l.e.  Normal,  XORiANO). 

msg<  graphlcs-class/setScreenModeMmode] ) 

setOutputMode 

funclton:  Sets  the  mode  In  which  output  Is  sent  to  the  display 
processeor  (l.e.  graphics  or  alphanumeric). 
msg(  graphlca-class/setOutputModeMmode] ) 

drawPofnt 

function:  Draws  a  point  In  the  graphics  environment 
msg(  graphlcsLXlass/drawPointMxUyUcolor] ) 

drawRect 

function:  Draws  a  rectangle  In  the  graphics  environment 
msg(  graphlcs-.class#“drawRectMleftlJ[bottomUr1ght],[topJ,  [color]) 

drawCircle 

function:  Draws  a  circle  In  the  graphics  environment 
msg(  graphics_class/drawClrcleMx]l[yUcolorj ) 
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draw  Polygon 

function:  Draws  a  polygon  In  the  graphics  environment. 
msgfgraphlcsLXlass/drawPolygonMpoly-obJect]) 

drawText 

function:  write  a  text  string  in  the  graphics  environment. 
msg(  graphicsLXlass/drawText^JxUyhlstzeUcolor] ) 

solfdFf  II 

function:  Enables  or  disables  solid  filling  of  shapes. 
msg(  graphica-class/solldFIIIMflagJ ) 

flushEvents 

function:  Removes  all  events  from  the  event  queue. 
msg(  graphicsLClass/f  lushEvent" ) 

sltowCrossHalrs 

function:  Display  the  cursor  crosshairs, 
msg (  graphic&jclass/showCrossHairs*) 

hldeCrossHairs 

function:  Hides  the  cursor  crosshairs. 
msg(  graphicsL.class/hldeCrossHairs") 
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Class:  graphic  list 
Suoar  Class:  link  list 
Class  Varlablas:  none 

cirajitihofla; 


new 

function:  Instantiates  a  graphic  list  object 

gJJst  ■  (node-type  *)  msg(  graphical  lsL-class,"new" ) 


none 


lnatinct.MtUHHte? 

whoOwnsPoInt 

function:  Answers  with  the  object  that  contains  the  point, 
owner  *  (node-type  *)  msg(  gJist/whoOwnsPolnt\[x],[y] ) 

InsertByArea 

function:  Adds  an  object  to  the  list  according  to  the  object's  area 
(acsending  order). 

msg(  g-llst/insertByAreaMobJectl ) 

Internals 

function:  Prints  the  instance  variables  of  all  the  objects  in  the  list. 
msg(  gJIst, ‘internals* ) 
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jSiiML  Class:  object 
Class  Variables;  non* 

Cl«88  fllthfldfi: 


ntw 

function:  instantiates  a  liQk  list  object, 
list  •  (node-type  *)  msg(  list-class, “new* ) 


member-count  :  number  of  elements  tn  the  list, 
head  :  first  element  in  the  list, 

tail  :  last  element  In  the  list 

InitinfifltethQda; 

t8£mpty 

function:  Answer  whether  the  list  contains  any  elements, 
reply  ■  (BOOLEAN)  msg(  Ilst/lsEmpty" ) 

getCount 

function:  Answers  with  the  number  of  elements  in  the  list, 
count  ■  (int)  msg(  Ilst/getCount" ) 

addTo 

function:  Appends  an  object  to  the  list. 
msg(  1 1st, 'addTo",  [an-object] ) 

AddToFront 

function:  Adds  an  object  to  the  front  of  the  list. 
msg(  Hst/addToFront\[an_objectl ) 

InsertBefor* 

function:  Inserts  an  object  into  the  list  before  a  specific  location. 
msg(  llst,M1nsertBefore",  [location],  [an— object] ) 
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getObject 

function:  Answers  with  the  object  from  the  list 
object  -  (node-type  *)  msg(  Ust/getObJect\  [nj ) 

JeleteObJect 

function:  Removes  an  object  from  the  list 
msg(  ]ist/deleteOtoject\  taojobJectJ) 

freeObJects 

funciton:  Deletes  all  objects  from  the  list 
msg(  1 1 st/ freeObJects" ) 
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elm  text  list 
Super  Class:  link  list 
Class  Variables:  none 


MW 

function:  Instantiates  a  text  list  object 

tJIst  ■  (node-type  *)  msg(  text-1  ist-class/new" ) 


none 


Instance  Methods: 
start  Write  At 

function:  Defines  the  starting  location  to  begin  writing  the  first 
text  object  in  the  list  The  remaining  text  object  will 
begin  at  the  same  x  cordinate  but  will  be  offset  In  the 
y  direction. 

msg(  t-.list/startWrlteAt\[x],[y] ) 

Internals 

function:  Prints  the  instance  variables  of  all  the  text  objects  in  the 
list 

msg(  t_l  1st/ Internals' ) 
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The  Raster  Technologies  Model  One/25  graphic  processor  can  be 
configured  to  communicate  with  a  number  of  different  host  computers,  it  is 
essential  that  a  proper  configuration  be  established  with  the  host  computer 
to  ensure  meaningful  communication. 

The  VAX  1 1/785  requires  that  all  data  sent  between  It  and  the  Model 
One/25  be  formated  as  7  bits,  even  parity.  It  Is  critical  that  the  Model 
One/25  be  configured  for  7  bits,  even  parity  communication  before  any 
attempt  is  made  to  run  the  ALC  protoype  software.  If  not  configured 
properly,  all  data  sent  to  the  Model  one/25  will  be  ignored.  The  following 
steps  outline  a  procedure  for  configuring  the  Model  One/25  to  handle  7  bit, 
even  parity  data 

step  1:  ‘Cold  Boot  the  Model  One/25. 

This  Is  performed  by  pressing  the  ’cold  boot  button  located  on  the 
rlght-liand  rear  comer  of  the  Model  One/25  processor.  This  action  will 
cause  the  Model  One/25  to  boot  with  Its  current  configuration. 

step  2:  Enter  graphics  mode'. 

From  the  alphanumeric  terminal  connected  to  the  Model  One/25  enter  a 
<CTRL  D>  or  <CTRL  E>.  The  system  should  respond  with  a  exclamation  point 
(l).  The  exclamation  point  Indicates  that  the  Model  One/25  Is  In  'graphics 
mode*. 
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TABLE  Vlil 

Communication  Configuration  for  the  Mode)  One/25  and  the  VAX  1 1  /785 


PORT  RTS  CTS  STOP  BITS  KIN  HOUT  CTRL  PARITY  BRUO 


ALPHAS 10 

OFF 

OFF 

2 

8 

ON 

OFF 

ON 

NONE 

9600 

M00EMSI0 

OFF 

OFF 

1 

8 

ON 

OFF 

OFF 

NONE 

1200 

6RINSI0 

OFF 

OFF 

2 

7 

OFF 

OFF 

OFF 

NONE 

1200 

TABLETS  10 

OFF 

OFF 

2 

8 

OFF 

OFF 

OFF 

NONE 

1200 

KEVBSIO 

OFF 

OFF 

1 

B 

ON 

OFF 

ON 

NONE 

300 

HOSTSIO 

OFF 

OFF 

2 

7 

OFF 

ON 

ON 

EUEN 

9600 

IEEE  port : 

mode 

■off 

address 

-0000 

Host  mode  Is  HEHRSCII 


ROM  sequence  number  Is  00 1 
Special  Characters : 

EntGr  Break  Ularrn  Kill  BS  RCK  Abort  Debug  HON  HOFF 
0005  0010  001B  0040  0008  0007  0015  0018  0011  0013 


Step  3:  Display  the  current  configuration. 

Type  dlscfg  at  the  prompt. 

Idlscfg  <CR> 

The  current  Model  One/25  configuration  should  be  displayed.  Check  this 
configuration  against  the  configuration  shown  In  Table  VIII.  If  the  HOSTSIO, 
Host  Mode,  and  Special  characters  are  the  same,  then  the  Model  One/25  is 
correctly  configured.  Skip  the  remaining  steps  in  this  procedure  by  typing: 

I  quit  <CR> 

otherwise,  proceed  with  the  following  steps. 


Appendix  E 


143 


SUn  4:  Set  Special  Characters. 

If  the  special  characters  are  correct  proceed  to  step  5,  otherwise  enter 
the  following  at  the  prompt* 

Ispchar  0,1,5  <CR> 

Ispchar5,l,7  <CR> 

This  will  set  the  'enter  graphics’  character  to  a  CTRL  E>  and  the 
'acknowledge’  character  to  a  <CTRL  6>. 

i 

Stan  5:  Set  HOSTSIO  Line. 

If  the  HOSTSIO  line  is  correct  proceed  to  step  6,  otherwise  enter  the 
following  at  the  prompt 

I  syscfg  serial  hosts lo  rts  off  cts  off  stop  2  bits  7 
parity  e  baud  9600  xfn  off  xout  on  Ctrl  on  <CR> 

The  system  should  respond  with: 

art  you  sure? 

Answer: 
yes  <CR> 

The  Model  One/25  will  perform  a  'warm  boot',  exiting  you  from  the 
‘graphics  mode'.  Reenter  'graphics  mode’  by  typing  CTRL  E>.  At  the  prompt 
type  discfg  and  verify  that  the  HOSTSIO  line  that  was  entered  is  correct  If 
it  is  incorrect,  repeat  this  step,  otherwise  continue. 

Step  6:  Set  Host  Mode. 

If  the  host  mode  is  correct  (i.e.  HEXASCII),  proceed  to  step  7,  otherwise 
set  the  host  mode  by  typing: 

I  syscfg  host  hostslo  ascii  <CR> 
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The  system  should  respond  with: 

are  you  sure? 

Answer. 

yes  <CR> 

Again  the  Model  One/25  will  perform  a  'warm  boot*.  Reenter  ‘graphics 
mode'  with  a  <CTRL  E>.  Type  dfscfg,  verify  the  results,  and  repeat  this  step 
if  necessary. 

Step  7:  Saving  the  Configuration. 

To  save  this  configuration  to  the  Model  One/25s'  non-volatile  memory, 

type: 

I  savcfg  <CR> 

The  system  should  respond  with: 

are  you  sure? 

Answer 

yes  <CR> 

At  this  point  the  correct  configuration  has  been  saved.  Communication 
between  the  VAX  1 1/785  and  the  Model  One/25  graphic  processor  Is  now 
possible. 

Since  all  configuration  data  Is  stored  in  non-volatile  memory,  this 
configuration  should  remain  until  the  configuration  Is  physically  modified 
again.  Performing  a  'cold  boot'  or  powering  down  the  Model  One/25  will  not 
change  this  conf  Iguratloa 

WARNING.  WARNING.  WARNING: 

Configuration  changes  should  not  be  attempted  while  the  Model  One/25 
is  connected  (logged  on)  to  the  VAX  1 1/785.  Configuration  changes  at  this 
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time  will  usually  causa  tha  Modal  One/25  to  lock  up.  Thera  is  no  daflnlta 
way  of  'unlock'  tha  Modal  Ona/25.  Somatlmes  the  system  will  remain  idle 
for  hours  before  it  will  respond 
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Anpudlx  F:  Divlci  Drivers 


The  functions  Implemented  In  this  device  driver  package  represent  just 
a  small  set  of  available  functions  needed  to  fully  exploit  the  capabilities  of 
the  Raster  Technologies  Model  One/25  graphic  system. 

All  modules  Implemented  In  this  package  were  written  in  *C\  They 
perform  no  error  checking  on  operand  values.  They  are,  however, 
syntactically  Identical  to  graphic  routines  defined  In  the  Raster 
i  chnologles  Programming  Guide  [Raster  Technologies,  1 9831 

The  Internal  processing  of  the  modules  were  modeled  after  an  earlier 
Pascal  Implementation  [Suzuki,  1 9831  Bascially,  they  convert  an  interger 
value  (operator  or  operand)  Into  a  hexldeclmal  ascii  string  representation. 
This  string  Is  then  sent  to  the  Model  One/25  via  the  'putchar*  command.  The 
model  One/25  interprets  the  string  and  performs  the  desired  operation.  For 
example,  the  opcode  to  clear  the  display  screen  is  135.  This  value  is 
converted  to  a  ascii  string  of  *87  and  sent  to  the  Model  One/25,  interpreted 
and  the  screen  cleared.  All  modules  defined  in  this  package  function 
similarly. 

A  listing  of  the  implemented  modules  follows,  accompanied  by  a  brief 
explanation.  The  reader  should  refer  to  the  Raster  Technologies 
Programming  Guide  for  complete  description  of  these  modules  and  other 
commands  supported  i ,  *  Model  One/25. 

ack()  :  sends  an  acknowledgment  (octal  07)  to  the  Mode)  One/25 

after  an  read. 

alpha_mode() :  puts  the  Model  One/25  Into  an  alpha-numerics  mode. 
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buttbl(l,m) 

ctrcle(r) 


assigns  a  macro,  m(  with  a  particular  mouse  button,!. 

draws  a  circle  of  radius  r  at  the  current  point 

clearO  :  clears  the  display  screen  with  the  current  color. 

cload(r,x,y)  :  loads  coordinate  register,  r,  with  x,y. 

cmove(d,s)  :  copies  the  contents  of  coordinate  register,  s,  into 
coordinate  register  d. 

cororg(x,y)  :  sets  the  coordinate  origin  register  to  x,y. 

drwabs(x,y)  :  draws  a  line  from  the  current  point  to  x,y. 

flushO  :  empties  the  event  queue. 

graplumodeO  :  puts  the  Model  One/25  into  graphics  mode. 

macdef(n)  :  begins  the  nth  macro  definition. 

macendO  :  ends  a  macro  definition. 

macera(n)  :  clears  the  nth  macro  definition. 

moddis(flag)  :  changes  the  displays  address  mode. 
flag-0  :  512x512 
-1  :  1024x1024 

movabs(x,y)  :  changes  current  point  to  x,y. 

pixfun(mode)  :  sets  the  way  In  which  Images  are  drawn  on  the  screen, 
mode  -  0  :  normal 
■  4  :  XOR 
■5  :  OR 
-6  :  AND 

pointO  :  displays  the  current  point. 
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prmflKf  lag)  :  sets  the  primitive  to  be  filled  or  unfilled, 
flag  ■  0  :  unfilled 
-  I  :  filled 


readbuCflag^ctlr^utton^y)  :  returns  the  function  button  and  cursor 

location. 

readcr(r,x,y)  :  returns  the  values  x,y  from  the  register  r. 

rectan(x,y)  :  draws  a  rectangle  with  the  lower  left  hand  comer  at  the 
current  point  and  the  upper  right  hand  comer  a  x,y. 

scrorgfoy)  :  sets  the  screen  coordinate  register  to  x,y. 

text  l  (string)  :  draws  a  text  string  starting  at  the  current  point. 

textc(s.a)  :  specifies  size  (s)  and  angle  (a)  of  next  text  draw. 

value(r,g,b)  :  changes  the  current  pixel  color. 

0  <-  r^b  <■  255 

windowCx^yl^yJ)  :  defines  the  clipping  window. 

xhairfn/lag)  :  enables  crosshair  n. 

flag-0  :  disable 
-  I  :  enable 
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